データベースの深淵を制御せよ：WP_Queryの物理レイヤを最適化するインデックス戦略
WordPressの`WP_Query`は万能だが、大規模なデータセットを扱う際、その柔軟性はしばしば「パフォーマンスの死」を招く。特にカスタム投稿タイプ（CPT）が混在する巨大な`wp_posts`テーブルにおいて、MySQLのクエリプランナが誤ったインデックスを選択した瞬間、システムはFPMのワーカーを枯渇させ、I/O待ちの地獄へと落ちる。
本稿では、WordPressの抽象化レイヤを剥ぎ取り、MySQLのストレージエンジンレベルで実行計画を強制的に最適化する技術的アプローチを解説する。
—
1. 悲劇のクエリプランナ：なぜ `post_type` は罠なのか
`wp_posts`テーブルの標準的なインデックス構成を確認したことはあるだろうか。多くの環境で `post_type` は単体、あるいは限定的な複合インデックスに含まれているに過ぎない。
— よくある低速クエリの典型
SELECT SQL_CALC_FOUND_ROWS
FROM wp_posts
WHERE post_type = ‘my_custom_type’
AND post_status = ‘publish’
ORDER BY post_date DESC
LIMIT 10;
MySQLのオプティマイザは、`post_type` のカーディナリティ（値の多様性）が低い場合、インデックスを無視してフルテーブルスキャン（ALL）を選択することがある。数百万レコードのテーブルにおいて、これは致命的なI/Oペナルティだ。
2. 複合インデックスの設計：カーディナリティの最大化
特定のCPTにおいて検索性能を極限まで高めるには、`post_type`、`post_status`、そして`post_date`を網羅する「カバリングインデックス」を構築する必要がある。
実践：最適化されたインデックスの構築
以下のDDLを実行し、MySQLのB-Treeインデックスを最適化する。
— 複合インデックスの追加
— post_type で絞り込み、post_status でフィルタし、post_date でソートする
— この順序がクエリプランナにとって「最も自然なパス」となる
ALTER TABLE wp_posts
ADD INDEX idx_cpt_status_date (post_type, post_status, post_date DESC);
なぜこの構成か？
- 左端プレフィックスルール: `post_type` が先頭にあることで、MySQLは該当CPTのセグメントへ一気にジャンプできる。
- ソートの回避: `ORDER BY post_date DESC` がインデックスの順序と一致するため、MySQLは「Filesort」というメモリを大量消費するソート処理をスキップできる。これがパフォーマンス向上の鍵だ。
3. WP_Queryと実行計画の強制（FORCE INDEX）
インデックスを作成しても、MySQLが古い統計情報を元に旧来のプランを選択し続ける場合がある。これを強制的にオーバーライドするために、`posts_clauses` フィルタを用いてクエリを直接制御する。
add_filter(‘posts_clauses’, function($clauses, $query) {
global $wpdb;
// 特定のクエリのみに介入する
if ($query->get(‘post_type’) === ‘my_custom_type’) {
// FORCE INDEX を挿入して、オプティマイザの迷走を断つ
$clauses[‘join’] .= ” FORCE INDEX (idx_cpt_status_date) “;
}
return $clauses;
}, 10, 2);
このコードは、WordPressの抽象化レイヤを突き破り、SQLの実行計画をハードコーディングする行為に近い。`posts_clauses` は非常に強力だが、同時にリスクも伴う。必ず `EXPLAIN` コマンドで実行計画を確認すること。
4. 検証：EXPLAINによるボトルネックの可視化
インデックス適用前後の差分を測るための作法だ。MySQLコンソールで以下を実行せよ。
EXPLAIN SELECT FROM wp_posts
WHERE post_type = ‘my_custom_type’
AND post_status = ‘publish’
ORDER BY post_date DESC
LIMIT 10;
- type: `ref` または `range` であること。`ALL` なら失敗だ。
- key: 作成した `idx_cpt_status_date` が表示されていること。
- Extra: `Using filesort` が消えていることが、最適化成功の証明だ。
5. 伝説のエンジニアへのアドバイス
インデックスは「諸刃の剣」である。読み込み性能を向上させる一方で、書き込み（INSERT/UPDATE）時のインデックス更新コストは増大する。
1. 書き込み頻度を考慮せよ: 毎秒数千件の投稿が発生する環境では、このインデックスは逆にオーバーヘッドとなる。
2. メモリ最適化: `innodb_buffer_pool_size` が物理メモリの70-80%に設定されているか常に確認せよ。インデックスがメモリに乗り切らなければ、結局ディスクI/Oが発生し、理論上の最適化は無意味と化す。
3. 統計情報の更新: `ANALYZE TABLE wp_posts;` を定期的に実行し、MySQLの統計情報を最新に保て。
WordPressという「黒箱」の中で起きていることを可視化し、DBという物理基盤を制御できた時、あなたのシステムは初めて「スケール」という概念を理解する。健闘を祈る。