なぜその `WP_Query` は、本番環境のデータベースを殺すのか
コードレビューをしていて、最も背筋が凍る瞬間の一つがこれだ。
// 最悪のアンチパターン
$query = new WP_Query([
‘post_type’ => ‘product’,
‘posts_per_page’ => 50,
]);
「ただ最新のプロダクトを50件取得しているだけじゃないか」と思ったとしたら、君のWordPressエンジニアとしてのキャリアは危うい。この数行の裏で、データベースに対して何が起きているか、SQLのレイヤーまで正確に脳内トレースできているだろうか？
結論から言おう。デフォルトの `WP_Query` は、取得した投稿のすべてのカスタムフィールド（postmeta）を、一つの巨大なSQLクエリで一括フェッチする。
50件の投稿があり、各投稿に平均10個のメタデータがあれば、$50 \times 10 = 500$ 行のレコードを `LEFT JOIN` または `IN` 句を使った重いクエリでメモリ上にロードし、それをハッシュマップ（キャッシュ）に構築する。
もしそれがトップページで、しかもオブジェクトキャッシュ（Redis/Memcached）が入っていない環境だったらどうなるか？
ページビューが伸びた瞬間、MySQLのCPU使用率は跳ね上がり、スロークエリの山が築かれ、最終的にインフラがダウンする。
今回は、この無駄なデータベースへの負荷を断ち切り、システムを極限まで最適化するための鍵――`update_post_meta_cache` の制御と、メタデータキャッシュのアーキテクチャの核心について解説する。
—
内部コアの理解：`WP_Query` は裏で何をしているのか
WordPressのクエリライフサイクルにおいて、`WP_Query::get_posts()` が実行された直後、次のような条件分岐が存在する。
// wp-includes/class-wp-query.php の内部イメージ
if ( $this->get( ‘update_post_meta_cache’ ) ) {
update_meta_cache( ‘post’, $post_ids );
}
この `update_post_meta_cache` のデフォルト値は `true` だ。
親切心から、WordPressは「後からどうせ `get_post_meta()` が呼ばれるだろう」と予測し、該当する投稿群の全メタデータを先回りしてキャッシュ（`wp_cache_add`）に詰め込もうとする。
だが、開発現場の現実を見つめ直してほしい。
私たちが構築するエンタープライズサイトやAPI連携システムにおいて、一覧画面（アーカイブやRESTのリストエンドポイント）で表示するのは、せいぜい「タイトル」「サムネイル」「パーマリンク」、そして特定の「価格（price）」くらいのものだ。
それなのに、SEOの内部フラグ、外部APIの同期ステータス、過去の移行スクリプトが残したゴミメタデータまで含めて、すべてのメタデータをロードする必要がどこにある？
答えは「ない」。
—
解決策：`update_post_meta_cache => false` の実践
不要なメタデータキャッシュの生成を抑制するには、`WP_Query` の引数に `update_post_meta_cache => false` を明示的に渡す。これだけで、あの忌々しいメタデータ取得用の重い追加クエリは完全に消滅する。
しかし、ここでエンジニアなら誰もが疑問に思うはずだ。
「キャッシュを切ったら、テンプレート側で `get_post_meta()` を叩いたときに、毎回個別でDBクエリが走って（N+1問題）、かえって遅くなるんじゃないですか？」と。
その通り。愚直に書けばN+1問題の罠にハマる。
だからこそ、プロのエンジニアは「必要なデータだけを、一括で、カスタムSQLまたは最適化された関数で取得する」という設計上のアプローチをとる。
プロダクションコード例：堅牢かつ高速なカスタムクエリ設計
以下のコードは、大量のカスタム投稿から「必要なメタデータ（価格と在庫ステータス）のみ」を効率的に取得し、メモリとDBの負荷を最小限に抑えるプロダクションクエリの設計パターンだ。
/
- 最適化されたプロダクト一覧取得関数
- @return array 投稿オブジェクトと必要最小限のメタデータを統合した配列
/
function get_optimized_products_data( int $limit = 20 ): array {
// 1. メタデータの自動キャッシュを無効化してWP_Queryを実行
$query = new WP_Query([
‘post_type’ => ‘product’,
‘posts_per_page’ => $limit,
‘post_status’ => ‘publish’,
‘orderby’ => ‘date’,
‘order’ => ‘DESC’,
‘update_post_meta_cache’ => false, // ★ ここが肝：不要な全件メタキャッシュを抑制
‘update_term_cache’ => false, // ターム（タクソノミー）も不要なら切る
]);
if ( empty( $query->posts ) ) {
return [];
}
$post_ids = wp_list_pluck( $query->posts, ‘ID’ );
// 2. 必要なメタデータ（例: _price と _stock_status）のみを、効率的な単一クエリで一括取得
global $wpdb;
$id_placeholders = implode( ‘,’, array_fill( 0, count( $post_ids ), ‘%d’ ) );
// プリペアドステートメントでSQLインジェクションを完全に防ぐ
$meta_results = $wpdb->get_results(
$wpdb->prepare(
“SELECT post_id, meta_key, meta_value
FROM {$wpdb->postmeta}
WHERE post_id IN ($id_placeholders)
AND meta_key IN (‘_price’, ‘_stock_status’)”,
…$post_ids
)
);
// 3. メタデータを投稿IDごとに綺麗にマッピング（O(N)のアルゴリズム）
$meta_map = [];
foreach ( $meta_results as $row ) {
$meta_map[ $row->post_id ][ $row->meta_key ] = $row->meta_value;
}
// 4. 投稿データとメタデータを結合して軽量なレスポンスを構築
$optimized_data = [];
foreach ( $query->posts as $post ) {
$optimized_data[] = [
‘id’ => $post->ID,
‘title’ => $post->post_title,
‘permalink’ => get_permalink( $post ),
‘price’ => $meta_map[ $post->ID ][‘_price’] ?? 0,
‘in_stock’ => ( $meta_map[ $post->ID ][‘_stock_status’] ?? ‘out’ ) === ‘instock’,
];
}
return $optimized_data;
}
この設計の優れている点
1. 不要なオーバーヘッドの排除: `update_post_meta_cache => false` により、無関係な数百行のメタデータロードを行わない。
2. N+1問題の回避: メタデータを `IN` 句で一度に取得し、PHP側でメモリ上でマッピングしているため、ループ内でクエリが追加発行されない。
3. メモリ効率の最適化: WordPressの肥大化した `WP_Post` オブジェクトやグローバルキャッシュを汚染せず、必要なプリミティブなデータ構造だけを返却するため、REST APIのレスポンス生成やGraphQLのResolverとしても非常に相性が良い。
—
パフォーマンス上の注意点とインデックスチューニング
上記のカスタムSQLを書く上で、データベース管理の観点から絶対に忘れてはならないのがインデックス（索引）の存在だ。
`wp_postmeta` テーブルのデフォルトのスキーマには、`(post_id, meta_key)` の複合インデックス（または個別のインデックス）が存在する。
しかし、データ量が数百万件規模に達すると、`meta_key IN (‘_price’, ‘_stock_status’)` の部分でフルスキャンが発生しやすくなる。
もし本番環境でこのクエリの実行速度が低下している場合は、MySQLのスロークエリログを解析し、以下の最適化をDBA（データベース管理者）と協議すべきだ。
— wp_postmeta の検索効率を極限まで高めるための複合インデックス例
ALTER TABLE wp_postmeta ADD INDEX post_id_meta_key_val (post_id, meta_key(191), meta_value(100));
(※インデックスのプレフィックス長は環境やカラムの文字コードに依存するため、実環境の検証が必須)
—
テクニカルリードからの総括
「WordPressは遅い」と嘆くエンジニアのコードを覗いてみると、大抵がこのようなコアの挙動を理解せず、デフォルトのAPIを思考停止で叩いている。
フレームワークやCMSの「便利さ」は、往々にしてパフォーマンスの「代償」の上に成り立っている。
内部コアが何をやっているのか（Under the hood）を看破し、必要な部分だけを自らの手でコントロールする――それこそが、プロフェッショナルなWebエンジニアと、単なるプラグイン設定者の決定的な違いだ。
次のスプリントでは、君が担当しているプロダクトの `WP_Query` をすべて洗い出し、不要なメタデータキャッシュが生成されていないかコードレビューを行ってほしい。データベースは、確実にその恩恵に応えてくれるはずだ。