WP_Queryの限界を超える：`post_parent`検索を爆速化する複合インデックス設計とデータベース最適化
テックリードの私だ。コードレビューの際、「階層構造のデータを取得するために `WP_Query` で `post_parent` を指定しているが、データ量が増えてからレスポンスが数秒に悪化した」という相談を後を絶たないほど受ける。
君たちは `WP_Query` に配列を渡せばよしなに動くと思っていなか？残念ながら、WordPressのコアテーブル構造とMySQLのオプティマイザの挙動を理解していなければ、数百万件規模の投稿データを持つシステムにおいて、データベースは容易に悲鳴を上げる。
今回は、`post_parent` 検索におけるボトルネックの正体を暴き、MySQLのインデックスチューニングとコードレベルの最適化によって、このクエリをミリ秒単位まで高速化する実践的アプローチを伝授する。
—
1. なぜ `post_parent` 検索はスケールしないのか？
まず、WordPressの心臓部である `wp_posts` テーブルの構造を直視しよう。
階層構造を持つカスタム投稿タイプ（例えば、ECのカテゴリ階層、ドキュメントのツリー構造など）において、特定の親IDに紐づく子投稿を一括取得する場合、多くの開発者は以下のようなコードを書く。
// よくある実装：一見問題なさそうに見えるクエリ
$args = array(
‘post_type’ => ‘my_product’,
‘post_parent’ => 12345,
‘posts_per_page’ => 20,
‘orderby’ => ‘menu_order’,
‘order’ => ‘ASC’,
);
$query = new WP_Query( $args );
この時、WordPressが内部で発行しているSQLの骨子はこうだ。
SELECT SQL_CALC_FOUND_ROWS wp_posts.
FROM wp_posts
WHERE wp_posts.post_type = ‘my_product’
AND wp_posts.post_parent = 12345
AND wp_posts.post_status = ‘publish’
ORDER BY wp_posts.menu_order ASC
LIMIT 0, 20;
コアの弱点：デフォルトインデックスの限界
WordPressの初期インストール時、`wp_posts` テーブルにはいくつかのインデックスが張られている。しかし、`post_type`、`post_parent`、`post_status`、`menu_order` が複雑に絡み合う検索において、MySQLのオプティマイザが最適な単一インデックスを選択できるとは限らない。
特に以下の2点がパフォーマンスを殺す。
1. `SQL_CALC_FOUND_ROWS` の呪い: WordPressはデフォルトで全該当件数を計算しようとするため、リミットをかけてもテーブルスキャンに近い負荷が発生する（※最新のWPコアでも注意が必要）。
2. インデックスの不整合: 単一カラムのインデックス（例: `post_parent` のみ）は存在しても、`post_type` で絞り込み、`post_parent` で一致させ、さらに `menu_order` でソートするような複合条件では、ファイルソート（Using filesort）が発生し、CPUを激しく消費する。
—
2. 解決策：マルチカラム（複合）インデックスの設計
データベーススペシャリストとして、ここで打つべき手は明確だ。「検索条件の絞り込み」と「ソート順」を完璧にカバーする複合インデックス（Composite Index）の追加である。
MySQLがインデックスを効率的に利用するための原則（左端プレフィックスの法則）に従い、以下の順序でカラムを並べたインデックスを設計する。
1. 等価検索（Equality）にするカラム：`post_type`, `post_parent`, `post_status`
2. ソート（Sorting）に使うカラム：`menu_order`（または `post_date`）
最適なインデックス追加SQL
以下のDDLを本番DB（またはマイグレーションスクリプト）で実行し、カスタムインデックスを付与する。
ALTER TABLE wp_posts
ADD INDEX idx_parent_optimization (post_type, post_parent, post_status, menu_order);
このインデックスがなぜ強力なのか？
MySQLは、`post_type` が一致し、次に `post_parent` が一致し、さらに `post_status` が一致するレコードの範囲をインデックスツリーから一瞬で特定し、すでに `menu_order` 順に並んでいるその範囲から上から20件（LIMIT 20）を正確に切り出すことができる。つまり、ファイルソートが完全に消滅するのだ。
—
3. プロダクションコード：最適化されたクエリの構築
インデックスを準備したら、次はそれを最大限に活かすPHP側の実装だ。
無駄なオーバーヘッド（特に `SQL_CALC_FOUND_ROWS`）を排除し、堅牢なキャッシュ戦略を組み合わせたプロダクションコードの模範解答を提示する。
/
- 高速化された子投稿取得関数
- @param int $parent_id 親投稿ID
- @param int $per_page 取得件数
- @param int $paged ページ番号
- @return WP_Post[] 投稿オブジェクトの配列
/
function my_get_optimized_child_posts( int $parent_id, int $per_page = 20, int $paged = 1 ): array {
$cache_key = “opt_children_{$parent_id}_p{$paged}_n{$per_page}”;
$cached_posts = wp_cache_get( $cache_key, ‘my_custom_queries’ );
if ( false !== $cached_posts ) {
return $cached_posts;
}
$args = array(
‘post_type’ => ‘my_product’,
‘post_parent’ => $parent_id,
‘posts_per_page’ => $per_page,
‘paged’ => $paged,
‘orderby’ => ‘menu_order’,
‘order’ => ‘ASC’,
// 【重要】ページネーション用の全件カウントを無効化し、クエリを高速化
‘no_found_rows’ => true,
// 【重要】オブジェクトキャッシュへのプレキャッシュを明示
‘update_post_meta_cache’ => false,
‘update_post_term_cache’ => false,
);
$query = new WP_Query( $args );
$posts = $query->posts;
// キャッシュに保存（1時間、投稿更新時にフラッシュする設計を推奨）
wp_cache_set( $cache_key, $posts, ‘my_custom_queries’, HOUR_IN_SECONDS );
return $posts;
}
コードの解説：なぜこの実装が優れているのか？
1. `no_found_rows => true`: 冒頭で触れた `SQL_CALC_FOUND_ROWS` を殺す。総件数を計算しないため、MySQLの内部テンポラリテーブル作成を防ぎ、クエリ実行速度が劇的に向上する。
2. メタ・タームキャッシュの抑制 (`update_post_meta_cache`, `update_post_term_cache`): 子投稿の一覧表示においてメタ情報やタクソノミーを個別に呼び出さないのであれば、これらのキャッシュ更新コストは完全な無駄である。メモリとCPUサイクルを節約せよ。
3. Object Cacheとの二段構え: DBへのヒット自体を減らすため、RedisやMemcachedなどの外部オブジェクトキャッシュ層と組み合わせ、アプリケーションレベルでミリ秒以下の応答速度担保する。
—
4. テックリードからの警告：インデックス運用の罠
最後に、データベースパフォーマンスを維持するための運用上の注意点を記しておく。
- 過剰なインデックスの弊害: 「すべてのカラムにインデックスを貼ればいい」という短絡的な思考は禁物だ。インデックスが増えるほど、投稿の新規作成・更新時（`INSERT` / `UPDATE`）の書き込みパフォーマンスが低下する。必ず `EXPLAIN` コマンドを用いて、本当にそのインデックスがクエリに使われているか（`type: ref` や `range` になっているか）を確認すること。
- データのカーディナリティ（分散度）: `post_status` のように値の種類が少ない（`publish`, `draft` 等）カラムをインデックスの先頭に持っていくのは悪手だ。しかし、今回の構成では `post_type`（カスタム投稿タイプの種類）と `post_parent`（高カーディナリティ）を先頭に置いているため、インデックスの選択性は非常に高い。
システムの規模が拡大した時、インサイトのないコードは必ずシステムを崩壊させる。コアの挙動をハックし、データベースの特性をねじ伏せるこの設計思想を、君たちのプロジェクトでも直ちに実践してほしい。