WordPressを掌握する極限の知見：WP_Query `meta_query` とインデックスの残酷な真実
コードレビューをしていて、次のようなコードに出くたことはないだろうか。
// 実務の現場で最も恐れられるアンチパターンの一つ
$query = new WP_Query([
‘post_type’ => ‘event’,
‘meta_query’ => [
[
‘key’ => ‘_is_featured’,
‘compare’ => ‘EXISTS’,
],
],
]);
一見すると、「`_is_featured` というメタキーが存在する投稿（＝おすすめイベント）をすべて取得する」だけの、何の変哲もないクエリに見える。しかし、これが数百万レコードを抱えるプロダクション環境に投入された瞬間、データベースのCPU使用率は跳ね上がり、スロークエリログの常連となる。
なぜか？今回は、WordPressの心臓部である `wp_postmeta` テーブルの構造を解剖し、`meta_query` で `EXISTS` 句を極限まで高速化するためのデータベースインデックス設計と、プロダクションコードの書き方を徹底解説する。
—
1. なぜ `meta_query` の `EXISTS` は重いのか？（内部挙動の解剖）
WordPressのカスタムフィールド（ポストメタ）は、EAV（Entity-Attribute-Value）モデルという、RDBのアンチパターンを地で行く構造で `wp_postmeta` に保存されている。
CREATE TABLE wp_postmeta (
meta_id bigint(20) unsigned NOT NULL auto_increment,
post_id bigint(20) unsigned NOT NULL default ‘0’,
meta_key varchar(255) default NULL,
meta_value longtext,
PRIMARY KEY (meta_id),
KEY post_id (post_id),
KEY meta_key (meta_key(191))
) ENGINE=InnoDB;
デフォルトのWordPressが提供するインデックスは `post_id` 単体、または `meta_key` 単体（プレフィックス191文字）のみだ。
ここに `compare => ‘EXISTS’` を投げると、WP_Queryは何をするか。
内部で次のような（概念的な）SQLが発行される。
SELECT SQL_CALC_FOUND_ROWS wp_posts.
FROM wp_posts
INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
WHERE 1=1
AND wp_posts.post_type = ‘event’
AND wp_posts.post_status = ‘publish’
AND wp_postmeta.meta_key = ‘_is_featured’
GROUP BY wp_posts.ID
ボトルネックの正体
1. 無駄なJOINと一時テーブル: `wp_posts` と `wp_postmeta` の結合が発生し、さらに重複排除のために `GROUP BY`（または `DISTINCT`）が走ることで、MySQL内部で一時テーブル（Temporary Table）が生成されやすい。
2. インデックスの不活用（Index Skip Scan または Full Table Scan）: `meta_key` 単体のインデックスはあるが、MySQLのオプティマイザが「どの `post_id` がその `meta_key` を持っているか」を効率的に引くための複合インデックスが欠如しているため、行の絞り込み効率が最悪になる。
結果として、データ量がスケールするにつれてクエリの実行時間は線形（あるいはそれ以上）に悪化する。
—
2. 解決策：複合インデックス（Composite Index）の設計
この問題を根本から解決するには、データベース側へのアプローチが不可欠だ。WordPressコアファイルをハックすることはできないが、MySQLのインデックスチューニングは我々の手で行える。
`wp_postmeta` において、`EXISTS` 句（特定のキーが存在するかどうか）を爆速にするための理想的な複合インデックスはこれだ。
— メンテナンスウィンドウを設けて手動で適用するインデックス
ALTER TABLE wp_postmeta ADD INDEX meta_key_post_id_idx (meta_key(191), post_id);
なぜこの順番（`meta_key` -> `post_id`）なのか？
1. 左端プレフィックスの法則（Leftmost Prefix Rule）: B-Treeインデックスの性質上、検索条件の第一歩は絞り込み能力の高い `meta_key` であるべきだ。特定のメタキー（例: `_is_featured`）に絞り込んだ上で、そのキーを持つ `post_id` のリストをインデックス内だけで完結してスキャン（Index Range Scan）できるようになる。
2. テーブルアクセス（Filesort/Table Scan）の回避: カバーリングインデックス的な挙動を促し、実際の `wp_postmeta` テーブルデータへのランダムアクセスを劇的に削減できる。
—
3. 【プロダクションコード例】堅牢なカスタムクエリ実装
データベースの準備ができたら、次はアプリケーション層（PHP）だ。
単に `WP_Query` を叩くだけでなく、キャッシュ戦略やクエリの最適化（不要なSQL発行の抑制）を考慮した、プロダクション品質のコードを見てほしい。
以下のコードは、効率的なメタキーの存在チェックを行い、結果をオブジェクトキャッシュに載せる堅牢なリポジトリクラスの断片である。
/
class EventRepository
{
/
- おすすめイベントのID一覧を取得する（EXISTSクエリ最適化版）
- @param int $limit 取得件数
- @return int[] 投稿IDの配列
/
public function get_featured_event_ids( int $limit = 10 ): array
{
$cache_key = ‘my_project_featured_event_ids_’ . $limit;
$cache_group = ‘events_query’;
// 1. 永続オブジェクトキャッシュ（Redis/Memcached）からのヒットを試みる
$cached_ids = wp_cache_get( $cache_key, $cache_group );
if ( false !== $cached_ids ) {
return $cached_ids;
}
// 2. WP_Query のパラメータ構築
$query_args = [
‘post_type’ => ‘event’,
‘post_status’ => ‘publish’,
‘posts_per_page’ => $limit,
‘fields’ => ‘ids’, // メモリ消費を抑えるためIDのみ取得
‘no_found_rows’ => true, // SQL_CALC_FOUND_ROWS を無効化して高速化
‘meta_query’ => [
[
‘key’ => ‘_is_featured’,
‘compare’ => ‘EXISTS’,
],
],
// オーダーを明示（必要に応じて）
‘orderby’ => [
‘date’ => ‘DESC’,
],
];
$query = new WP_Query( $query_args );
$post_ids = array_map( ‘absint’, $query->posts );
// 3. キャッシュの保存 (TTL: 1時間)
wp_cache_set( $cache_key, $post_ids, $cache_group, HOUR_IN_SECONDS );
return $post_ids;
}
}
このコードの美しさと設計ポイント
1. `’fields’ => ‘ids’` の徹底: 不要な `WP_Post` オブジェクトのインスタンス化コストを排除し、純粋なIDの配列のみを取得する。これによりメモリ使用量を最小化。
2. `’no_found_rows’ => true`: ページネーション（`max_num_pages`）が不要な場合、このパラメータを指定することで、MySQLの重い `SQL_CALC_FOUND_ROWS` クエリを完全にバイパスする。これだけでクエリの実行速度が数倍跳ね上がることもある。
3. オブジェクトキャッシュ層の挟み込み: どれだけDB側をチューニングしても、トラフィックが急増すればDBは悲鳴を上げる。アプリケーション層でのキャッシュ（Redis等）の併用が、真のスケールを生む。
—
4. テクニカルリードからの最終インスペクション
コードレビューの際、ジュニア・中級エンジニアがよく犯すミスとして、「メタクエリに複数の条件を泥臭く追加していく」というものがある。
もし `EXISTS` と同時に値の比較（`value`, `compare => ‘=’`）を行う場合は、さらに注意が必要だ。
複合インデックスは、クエリの検索順序（左端から）と完全に一致している必要がある。
— 値の比較も頻繁に行う場合は、値を含めた複合インデックスを検討する
ALTER TABLE wp_postmeta ADD INDEX meta_key_value_post_id_idx (meta_key(191), meta_value(100), post_id);
(※ `longtext` 型である `meta_value` にインデックスを張る際は、必ずプレフィックス長を指定すること。)
まとめ
WordPressの柔軟性は、時としてデータベースへの無慈悲な負荷と表裏一体だ。
「なんとなく動くコード」を書くステージを脱却し、「MySQLが内部でどうインデックスを走査しているか（EXPLAINの結果）」を常に脳内でトレースしながらコードを書くこと。
それこそが、数百万PVのトラフィックを平然と裁く真のシニアエンジニアの流儀である。