実行計画（Execution Plan）の深淵：WP_Queryを解剖し、I/Oボトルネックを殲滅する
WordPressを「CMS」という高レイヤーな抽象概念で捉えているうちは、真のパフォーマンス改善には到達できない。我々が対峙しているのは、PHPというインタプリタ上で動作し、MySQLというRDBMSをバックエンドに持つ、極めて状態依存性の高い動的システムだ。
特に、`WP_Query`の背後で発行されるSQLは、開発者の意図しない「N+1問題」や「インデックス無視のフルテーブルスキャン」を誘発しやすい。本稿では、Query Monitorを単なるデバッグツールとしてではなく、データベース・エンジンの挙動を可視化する「観測装置」として定義し、ボトルネックを排除する術を解説する。
—
1. Query Monitorで見出すのは「クエリの重さ」ではない、「I/Oの無駄」だ
多くの開発者は、Query Monitorで「クエリ実行時間」だけを見て満足する。だが、真に見るべきは「クエリの実行計画（EXPLAIN）」と「データセットの整合性」だ。
プラグインが不適切なクエリを発行すれば、MySQLのクエリキャッシュ（もし有効であれば）は汚染され、バッファプールは無用なデータで埋め尽くされる。メモリ最適化の第一歩は、この「無駄なI/O」を特定することから始まる。
Query Monitorを「観測装置」として活用するポイント
1. 「Queries by Component」を確認せよ：どのプラグインが発行したクエリが最もコストが高いか。
2. SQLの「Caller」を追跡せよ：単なるSQLではなく、どのフックやファイルからそのクエリが呼び出されたかというコールスタックを解析し、`pre_get_posts`のオーバーライドや無意味な`get_posts`を排除する。
—
2. データベースの深淵：インデックス・チューニングの鉄則
WordPressの `wp_posts` や `wp_postmeta` テーブルは、データ量が数百万件を超えると、単なるインデックスでは太刀打ちできなくなる。特に `meta_key` と `meta_value` を用いた結合は、非正規化された構造ゆえにコストが跳ね上がる。
インデックスの最適化例
もし、特定のメタキーで頻繁にフィルタリングしているなら、MySQL側で複合インデックスを検討すべきだ。だが、その前にやるべきは、不要な `meta_query` の排除である。
— 最適化のヒント：EXPLAINで見るべきは「type」と「rows」
— ALL となっていれば、それはフルテーブルスキャンを意味する
EXPLAIN SELECT FROM wp_postmeta WHERE meta_key = ‘target_key’ AND meta_value = ‘target_value’;
もし `type` が `ALL` であれば、即座にインデックスを追加せよ。
ALTER TABLE wp_postmeta ADD INDEX idx_meta_key_value (meta_key, meta_value(20));
(注意: `meta_value` は TEXT型であるため、接頭辞インデックスの長さ制限に注意すること)
—
3. コードレベルでの最適化：`WP_Query` をハックする
シニアエンジニアであれば、`WP_Query` をそのまま叩くのではなく、キャッシュ層を意識した実装を徹底すべきだ。
例えば、`get_posts()` よりも `WP_Query` オブジェクトを直接操作し、不要なメタデータやタームの取得を抑制するフラグを立てることで、メモリ消費量を劇的に抑えられる。
// パフォーマンスを極限まで最適化したクエリの例
$args = [
‘post_type’ => ‘post’,
‘posts_per_page’ => 10,
‘no_found_rows’ => true, // SQL_CALC_FOUND_ROWSを無効化（ページネーションが不要な場合、I/Oを激減させる）
‘update_post_meta_cache’ => false, // メタデータのキャッシュを無効化（ループ内でメタを使用しない場合）
‘update_post_term_cache’ => false, // タームキャッシュを無効化
];
$query = new WP_Query($args);
なぜ `no_found_rows` が重要か
デフォルトの `WP_Query` は、SQL内で `SQL_CALC_FOUND_ROWS` を実行する。これは全件カウントを行うために全インデックスを走査するため、大規模データベースでは致命的な遅延を生む。ページネーションを自前で実装するか、カウント不要な場合は必ず `true` に設定せよ。
—
結論：システムを支配せよ
プラグインが発行するクエリを可視化し、MySQLの挙動を理解することは、WordPressというブラックボックスを自身の制御下に置くことに他ならない。
1. Query Monitorで異常なクエリを特定せよ。
2. `EXPLAIN`で実行計画を精査し、インデックスが機能しているか確認せよ。
3. `no_found_rows` や `update_post_meta_cache` を制御し、データベースへの不要な介入を遮断せよ。
エンジニアリングとは、ツールの便利さに甘んじることではなく、その下のレイヤーで起きている物理的な動作を想像し、最適化し続けることだ。さあ、今すぐ管理画面のデバッグバーを開き、あなたのシステムが隠している「真実」を暴き出せ。