メタデータ地獄からの脱却：WP_QueryにおけるJOINの連鎖とインデックスの物理設計
WordPressを「ただのCMS」と呼ぶ者は、その内部で駆動する `wp_postmeta` テーブルの悲鳴を聞いたことがない。
シニアエンジニア諸君、今日我々が対峙するのは、`meta_query` が引き起こす「隠れたクエリ爆弾」だ。単なるSQL最適化の話ではない。MySQLのオプティマイザがなぜ複雑なクエリで迷走するのか、そしてなぜタクソノミーが物理ストレージレベルで優位性を持つのか。その真髄を解剖する。
—
1. なぜ meta_query は「悪」なのか：EAVモデルの限界
WordPressのメタデータ構造は、典型的な EAV（Entity-Attribute-Value）モデル だ。この構造は柔軟性という美徳と引き換えに、スケーラビリティという悪魔を召喚する。
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id)
WHERE wp_postmeta.meta_key = ‘status’ AND wp_postmeta.meta_value = ‘active’;
`meta_query` を多用すると、`wp_postmeta` に対して再帰的なJOINが発生する。投稿数が10万、メタデータが100万行を超えた瞬間、MySQLはインデックスの断片化と格闘し、フルテーブルスキャンの一歩手前でメモリを食いつぶす。
オプティマイザの迷宮
`meta_key` にインデックスがあっても、`meta_value` は `LONGTEXT` 型であり、デフォルトではインデックスが貼られていない。結果、`filesort` が発生し、一時テーブル（`tmp_table`）がオンメモリからディスクへ溢れる。これが高負荷時における「サイトが重い」の正体だ。
—
2. タクソノミー：物理的なデータ局所性の優位性
一方で、`wp_term_relationships` と `wp_term_taxonomy` を利用した構造を見てほしい。これらは正規化されたテーブルであり、`object_id` と `term_taxonomy_id` に対して複合インデックスが適切に貼られている。
- Meta Query: 属性検索のたびにEAVテーブルを全探索（あるいはインデックス跳躍）
- Taxonomy Query: B-Treeインデックスを通じた、ポインタによる直接アクセス
タクソノミーは「データ」を検索対象ではなく「インデックス」として扱う。これが検索速度を数桁向上させる物理的な理由だ。
—
3. 極限の最適化：カスタムインデックスとクエリの分離
どうしてもメタデータを使わなければならない局面はある。その場合、標準の `WP_Query` に依存するのは自殺行為だ。以下の戦略を推奨する。
A. 必要な時だけ「カスタムテーブル」に逃がす
高頻度でフィルタリングするデータは、`wp_postmeta` から切り出し、専用のテーブルを作成せよ。`post_id` を主キー（またはユニークインデックス）にした構造にすることで、`JOIN` を排除した単純な `SELECT` が可能になる。
/
- 専用テーブルからの高速検索ロジック
- WP_Queryを通さないことで、Object Cacheのオーバーヘッドと
- 不必要なJOINを完全に排除する
/
global $wpdb;
$post_ids = $wpdb->get_col( $wpdb->prepare(
“SELECT post_id FROM {$wpdb->prefix}custom_lookup_table WHERE status = %s”,
‘active’
) );
// WP_Queryは後からIDを渡すだけにする
$query = new WP_Query([
‘post__in’ => $post_ids,
‘post_type’ => ‘product’
]);
B. Index Hint の適用（上級者向け）
MySQLオプティマイザが最適でない実行計画を選択している場合、`posts_clauses` フックを使用して `FORCE INDEX` を挿入する。これは最後の手段だが、クエリキャッシュが効かない環境では劇的な効果を生む。
add_filter(‘posts_clauses’, function($clauses, $query) {
global $wpdb;
// 既存のJOIN句にインデックスヒントを強制注入する
$clauses[‘join’] = str_replace(
“INNER JOIN {$wpdb->postmeta}”,
“INNER JOIN {$wpdb->postmeta} USE INDEX (meta_key)”,
$clauses[‘join’]
);
return $clauses;
}, 10, 2);
—
4. 結び：エンジニアとしての矜持
WordPressのコアは、あくまで「汎用的な道具」だ。その汎用性を限界まで引き伸ばした結果が現在のメタデータ構造である。
シニアエンジニアがやるべきは、「デフォルトのWP_Queryが全てを解決してくれる」という幻想を捨てることだ。データベースの実行計画（`EXPLAIN`）を読み、キャッシュ層のメモリ使用量を監視し、必要であればコアの構造を裏切ってでも最適なクエリを投げる。
それが、我々が「伝説」と対峙するための唯一の道である。
次回の講義テーマ： `Object Cache` と `Transient API` の裏側。なぜ `Redis` を導入しても `get_posts` が遅いのか、オブジェクトシリアライズのコストを深掘りする。