巨大な `term_relationships` をねじ伏せろ：WP_QueryのJOIN地獄を脱却する最適化戦略
WordPressのスケーラビリティを語る上で、避けて通れないボトルネックが `term_relationships` テーブルだ。タクソノミーを多用するメディアやECサイトにおいて、ここが数百万行に達した瞬間、一般的な `WP_Query` は悲鳴を上げる。
なぜか？ 内部で発行される `INNER JOIN` が、インデックスの効きにくい巨大な中間テーブルを生成し、MySQLの実行計画（EXPLAIN）を破壊するからだ。本稿では、コアの挙動をハックし、JOINを回避して高速な検索を実現する「プロダクションレベル」の設計パターンを伝授する。
—
1. なぜ `WP_Query` はスケーリングで詰むのか
`tax_query` を用いたクエリは、WordPress内部で以下のようなSQLを生成する。
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id)
WHERE wp_term_relationships.term_taxonomy_id IN (10, 20)
…
データ量が増えると、`term_taxonomy_id` でフィルタリングした後のIDリストをメモリ上に展開し、さらに `wp_posts` とJOINするコストが指数関数的に増大する。これが、クエリが1秒を超える「死の瞬間」だ。
2. 脱・JOIN：メタ・クエリによる事前フィルタリング
JOINが遅いなら、JOINさせなければいい。タクソノミーの情報を `wp_postmeta` にフラットに書き出し、そこを検索対象にする手法がある。だが、もっとスマートかつ保守性の高いアプローチは、「タクソノミーのIDリストを事前取得し、`post__in` でピンポイントに叩く」ことだ。
実装パターン：キャッシュを活かした高速検索
この手法の肝は、`wp_get_object_terms` ではなく、`wpdb` を使って直接 `term_relationships` からIDだけを抽出し、それを `WP_Query` に渡すことにある。
/
- 複雑なJOINを回避し、term_relationshipsを直接叩いて高速化する設計
/
function get_optimized_posts_by_terms(array $term_ids, int $limit = 10) {
global $wpdb;
// 1. キャッシュキーの生成（クエリの正規化）
$cache_key = ‘opt_posts_’ . md5(implode(‘,’, $term_ids) . $limit);
$post_ids = wp_cache_get($cache_key, ‘custom_query’);
if (false === $post_ids) {
// 2. JOINを避け、対象IDのみを高速に抽出
// term_relationshipsは(object_id, term_taxonomy_id)でインデックスが貼られているため、
// 単一テーブルへの検索なら極めて高速
$post_ids = $wpdb->get_col($wpdb->prepare(
“SELECT DISTINCT object_id
FROM {$wpdb->term_relationships}
WHERE term_taxonomy_id IN (” . implode(‘,’, array_map(‘intval’, $term_ids)) . “)
LIMIT %d”,
$limit
));
wp_cache_set($cache_key, $post_ids, ‘custom_query’, HOUR_IN_SECONDS);
}
// 3. IDベースでWP_Queryを実行（post__inは最適化されている）
return new WP_Query([
‘post__in’ => !empty($post_ids) ? $post_ids : [0],
‘orderby’ => ‘post__in’, // 元の順序を保持
‘posts_per_page’ => $limit,
]);
}
—
3. この設計が「堅牢」である理由
1. インデックスの完全活用: `term_relationships` テーブルの複合インデックス `PRIMARY KEY (object_id, term_taxonomy_id)` を最大限に活かせる。`JOIN` が発生しないため、MySQLはテーブルスキャンを回避し、レンジスキャンで解決する。
2. キャッシュレイヤーの分離: `WP_Query` 全体をキャッシュするのではなく、タクソノミーによるID抽出結果のみをキャッシュする。これにより、投稿の更新（`save_post`）によるキャッシュパージの制御が容易になる。
3. クエリの予測可能性: `WP_Query` の `tax_query` は解析コストが高い。事前にIDを確定させることで、実行計画が安定する。
4. プロダクションにおける注意点
- `post__in` の罠: `post__in` に数千件のIDを突っ込むのはNGだ。SQLの `IN` 句の限界や、メモリ消費の問題が発生する。ページネーションが必要な場合は、`post__in` を使うのではなく、タクソノミー情報を持たせた専用のカスタムテーブルを作成し、`JOIN` させる方が長期的には安定する。
- キャッシュパージの自動化: `set_object_terms` などのフックを監視し、関連するタクソノミーが更新された際に、`wp_cache_delete` を実行する堅牢なパージロジックを必ず実装すること。
結論：システムを支配せよ
WordPressは「遅い」のではない。コアのデフォルト実装が、汎用性を重視するあまり、特定のユースケースでは効率を犠牲にしているだけだ。
大規模サイトを運用するエンジニアにとって、`WP_Query` はブラックボックスであってはならない。`$wpdb` で直接データを握り、必要なときだけオブジェクトの力を借りる。この「制御と抽象化のバランス」こそが、伝説級のシステムを構築する鍵となる。
さあ、コードを開き、その複雑な JOIN を断ち切る準備をしよう。あなたのサイトの応答速度は、その一行で劇的に変わるはずだ。