抽象化の代償：WP_Queryにおける「tax_query OR」の実行計画を解剖する
WordPressの`WP_Query`は、データベースの複雑性を隠蔽する極めて強力な抽象化レイヤーだ。しかし、この抽象化こそが、大規模データセットにおけるパフォーマンス崩壊の主犯となる。特に、`tax_query`における`’relation’ => ‘OR’`を指定した際、内部で生成されるSQLがいかに非効率な実行計画（Execution Plan）を導くか、その深淵を理解しているエンジニアは少ない。
我々のようなシステムアーキテクトが直面するのは、単なる「遅いクエリ」ではない。それは、ストレージエンジンのインデックス走査戦略と、WordPressコアが生成するレガシーな結合（JOIN）ロジックとの致命的なミスマッチである。
—
1. 内部メカニズム：なぜ「OR」はJOINを増殖させるのか
`wp-includes/class-wp-tax-query.php`のソースコードを追えば、WordPressがどのようにSQLをビルドしているかが明白になる。`tax_query`で複数のタクソノミーを`OR`で結合すると、コアはタクソノミーごとに`wp_term_relationships`テーブルを別名（エイリアス）でJOINし続ける。
— ‘category’ OR ‘post_tag’ を指定した場合の典型的な生成SQL
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts
LEFT JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id)
LEFT JOIN wp_term_relationships AS tt1 ON (wp_posts.ID = tt1.object_id)
WHERE 1=1
AND (
wp_term_relationships.term_taxonomy_id IN (10)
OR
tt1.term_taxonomy_id IN (20)
)
AND wp_posts.post_type = ‘post’
GROUP BY wp_posts.ID
このクエリの致命的な欠点は以下の3点だ。
1. デカルト積の膨張: `LEFT JOIN`が重なることで、中間結果セットのレコード数が爆発的に増加する。
2. インデックス・マージの不在: MySQLのオプティマイザは、同一テーブルに対する複数のエイリアスを跨いだ`OR`条件において、効率的なIndex Mergeを選択できないことが多い。
3. Temporary & Filesort: `GROUP BY wp_posts.ID`が強制され、メモリ上（あるいはディスク上）での一時テーブル作成とソートが発生する。これはバッファプールを汚染し、I/O Waitを増大させる。
—
2. インデックス・チューニングの限界と「サブクエリ化」の罠
多くの開発者は、`term_taxonomy_id`にインデックスを貼ることで解決を図る。しかし、B-treeインデックスは`OR`条件において、特に異なるテーブルエイリアスを跨ぐ場合、その真価を発揮できない。
また、`EXISTS`句を用いたサブクエリへの書き換えも検討に値するが、WordPressの`WP_Query`は標準でこれをサポートしていない。標準の`tax_query`を使い続ける限り、我々は「JOIN地獄」から逃れられないのだ。
—
3. 極限の最適化：`posts_clauses`によるSQLの再定義
真のシニアエンジニアは、`WP_Query`の抽象化を維持しつつ、フィルタフックを用いて生成されるSQLを外科手術のように修正する。`relation => OR`を回避し、単一のJOINと`IN`句、あるいはビット演算に近い効率的なフィルタリングへ変換する手法を紹介する。
戦略：JOINを一本化し、条件をWHERE句に集約する
複数のタクソノミーを`OR`で検索する場合、それらが同一のテーブル（`wp_term_relationships`）にあることを利用し、JOINを一つにまとめ、`WHERE`句で解決させる。
/
- WP_QueryのOR条件によるJOIN増殖を抑制する
- @param array $clauses SQLの各パーツ
- @param WP_Query $query クエリインスタンス
- @return array 修正されたクエリ
/
add_filter(‘posts_clauses’, function($clauses, $query) {
if (is_admin() || !$query->is_main_query()) return $clauses;
// 特定のクエリフラグが立っている場合のみ介入
if (!$query->get(‘optimize_tax_or’)) return $clauses;
global $wpdb;
/
- ロジック：
- 1. 既存の重複JOINを削除し、単一のJOINに統合
- 2. WHERE句を「ID IN (SELECT object_id FROM … WHERE term_id IN (A, B))」に書き換え
- これにより、MySQLのオプティマイザは単一インデックスのレンジスキャンを選択可能になる
/
// tax_queryの内容から対象のterm_taxonomy_idを抽出（ここでは簡略化）
$term_ids = [10, 20]; // 動的に取得するロジックが必要
$term_id_list = implode(‘,’, array_map(‘intval’, $term_ids));
// JOIN句の無効化（空にする）
$clauses[‘join’] = “”;
// WHERE句にサブクエリを注入（依存サブクエリを避け、定数リスト化）
$clauses[‘where’] .= ” AND {$wpdb->posts}.ID IN (
SELECT object_id
FROM {$wpdb->term_relationships}
WHERE term_taxonomy_id IN ($term_id_list)
)”;
// 重複排除のためのGROUP BYを不要にする
$clauses[‘groupby’] = “{$wpdb->posts}.ID”;
return $clauses;
}, 10, 2);
4. アーキテクチャレベルの回避策：非正規化とメタデータへの委譲
もしこのクエリが秒間数千リクエストに晒されるのであれば、RDBMSの正規化理論をあえて捨てる「非正規化」が正解となる。
1. タクソノミーのフラット化: 投稿保存時（`save_post`）に、検索対象となる複数のタクソノミー情報を単一のカスタムフィールド、あるいは専用の高速検索用テーブルにビットマスクやカンマ区切りで保存する。
2. Persistent Object Cacheの活用: `WP_Query`の結果そのものをRedisにキャッシュするのは基本だが、`tax_query`の組み合わせパターン（ハッシュ値）をキーとしたIDリストのキャッシュ戦略を構築せよ。
5. 結論：システムアーキテクトが持つべき視点
`WP_Query`は便利なライブラリであるが、その裏側で発行されるSQLは、計算量 $O(n^k)$（$k$はJOIN数）の爆弾を抱えている。
中級者から上級者へステップアップするためには、PHPのコードがどのようにSQL文へコンパイルされ、それがMySQLのストレージエンジンにおいてどのようにデータページをスキャンし、CPUサイクルとメモリ帯域を消費するのかを脳内でシミュレーションできなければならない。
`relation => OR`が必要になった時、安易にそのプロパティをセットするのではなく、「このクエリはインデックスを殺していないか？」と自問自答せよ。真の最適化は、コードを書かないこと、あるいは構造そのものを疑うことから始まる。