2014/08/30 に開催されたWordFes Nagoyaで使用したスライドです。

1. WordPress
DB & Performance
2014/08/30
Takayuki Miyauchi
初心者向け

2. 自己紹介

3. • フリーランス
• デジタルキューブの「め組」メンバー
• WordPressとかAWSとか、最近はオープンデー
タのコミュニティにも出没

7. デジタルキューブについて

8. • Amazon Web Service（AWS）
コンサルティングパートナー
• オープンソース大好き
（WordPress、Nginx、CKAN …）
• ほとんどのスタッフがリモートワーク
（神戸、東京、新潟、福岡、仙台、和歌山 …）

11. 今日のお話

12. • 初心者向けデータベースインデックス講座
• WordPressで重くなりがちな処理
• WordPressで重くなりがちなプラグインのパターン
• 質問タイム

13. インデックス講座

14. インデックスを使いこなすと
早くなるらしいぞ！

15. インデックスって？
• 索引のこと。
• 本で例えるとわかりやすいです。

16. 偶然にも手元に本があるのでこれで説明！

17. この本の中からwp_headという単語がある
ページを探すには２通りの方法があります。

18. 巻末の索引を見て探す。

19. 1ページずつ読んで探す。

20. • 索引を使ったほうが圧倒的に早い。
• 索引を使えば、ページ数が増えても検索に必要
な時間はほぼ同じ。
超重要！

21. DBに置き換えると
こうなります。

22. • インデックスを使ったほうが圧倒的に早い。
• インデックスを使えば、レコード数が増えても
検索に必要な時間はほぼ同じ。
超重要！

23. このあたりの挙動はSQLの
EXPLAINで確認できます。
EXPLAIN SELECT * FROM wp_posts WHERE …

24. テスト用のテーブルに
約3万2千件のレコードを放り込みました。
CREATE TABLE item (
id INT PRIMARY KEY AUTO_INCREMENT,
name1 VARCHAR(100), —— indexあり
name2 VARCHAR(100), —— indexなし
index(name1)
);

25. 以下のSQLは2つとも同じ結果が得られます。
• select * from item where name1 = ‘item-1’;
• select * from item where name2 = ‘item-1’;
ただし `name1` はインデックスあり、
`name2` はインデックスなしです。

26. mysql> select id from item where name1 = 'item-1';
+----+
| id |
+----+
| 1 |
+----+
1 row in set (0.00 sec)

27. でも負荷はまるで違う
EXPLAINの結果表示される表の `rows` は、
データを取得するために参照したレコードの数。

28. インデックスを使用しない場合、
必要な行がたったの1行でも、
データベースはすべてのレコードセットを参照します！
レコードが増えるほど重くなる！

29. そんなわけで
インデックスは超大事

30. WordPressで
重くなりがちな処理

31. インデックスが
効いてないクエリー
（例）

32. みんな大好き
カスタムフィールド！
meta_key meta_value

33. meta_valueにはインデックスが設定されてい
ないので、meta_valueを使った検索は重い。
$args = array(
'post_type' => 'product',
'meta_query' => array(
array(
'key' => 'featured',
'value' => 'yes',
)
)
);
$postslist = get_posts( $args );

34. 同じ理由でmeta_valueを使った
並べ替えも重い！
$args = array(
'post_type' => 'product',
'orderby' => 'meta_value',
'meta_key' => ‘age',
);
$postslist = get_posts( $args );

35. その他にも
• 頻繁に書込するのは重くなる。
• 大きなデータを保存すると重くなる。
• Transient APIは使い過ぎに注意。
• いろいろなテーマやプラグインのインストールとアンイン
ストールを繰り返すと、Optionsが肥大化して重くなる。

36. 重くなりがちな
プラグインのパターン

37. たとえば人気ランキング系
プラグイン
• 人気ランキングを生成するにはページにアクセスがあるた
びに、それをデータベースに保存する必要があるはず。
• 月別、週別など、柔軟にランキングを生成するには、サイ
トにアクセスがあるたびにページの情報と日付をデータベー
スに保存しているはず。
• 1日1,000PVあるサイトなら毎日1,000行のレコードがデー
タベースに追加されることになる。。。

38. このプラグインは
Google Analytics APIを使ってるので安心！
http://wordpress.org/plugins/simple-ga-ranking/
作者: @horike37さん

39. 言わずと知れたJetpackにも
人気ランキング機能があります。

40. その他にも
• Eコマース系のプラグインなどは、meta_valueによる検索
を多用してる場合があるので、それらのプラグインを使う
場合は要注意。
• 他にもいろいろあるはず。

41. プラグインを使う場合には、
想像力が大事！
これってDBに頻繁に
書き込みするのかな？
大きなデータを
保存してないかな？
このファイルは
どこに保存されるの？
どのテーブルに
保存するのかな？
どんなSQLを
実行してるの？

42. 遅いSQLの見つけ方

43. Debug Bar
https://wordpress.org/plugins/debug-bar/
開発者が豪華！

44. Debug Barを使うときは以下の設定を追加
define( 'WP_DEBUG', true );
define( 'SAVEQUERIES', true );

45. SQLの履歴が簡単に確認できます！

46. http://knowledge.sakura.ad.jp/tech/283/

47. そうは言ってもどうしても
使いたい時がある！

48. キャッシュ系プラグインではもっとも簡単で高速＆安心

49. DBにPerconaを使用
リバースプロキシを有効化すればさらに高速

50. 最後に宣伝

51. 「WordPressプラグイン開発のバイブル」
日本ではじめての開発者に
フォーカスした書籍です。

52. ありがとうございました！