【実務・中級編】上級プロフェッショナル向け：WP_Queryの実行フローにおける「SQLキャッシュ」の有効範囲と限界 – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

WordPressを掌握する極限の知見：WP_Queryにおける「SQLキャッシュ」の有効範囲と限界

コードレビューをしていて、次のようなコードに出くわしたことはないだろうか。

// よくある「とりあえずキャッシュさせよう」というアンチパターン
$cache_key = ‘complex_query_’ . md5(serialize($args));
$query = wp_cache_get( $cache_key, ‘my_custom_group’ );

if ( false === $query ) {
$query = new WP_Query( $args );
wp_cache_get_… いや wp_cache_set( $cache_key, $query, ‘my_custom_group’, HOUR_IN_SECONDS );
}

一見、データベースへの負荷を減らしているように見えるこのコード。しかし、大規模なトラフィックを扱うプロダクション環境においては、メモリリークの温床であり、キャッシュ汚染を引き起こす悪手だ。

今回は、WordPressの心臓部である `WP_Query` の内部実行フロー、オブジェクトキャッシュ層、そしてデータベース（MySQL/MariaDB）レイヤーにおけるクエリキャッシュの相互作用を解剖し、真にスケーラブルなクエリ最適化の設計思想を伝授する。

—

1. 内部解剖：`WP_Query` はSQLの実行時に何をしているのか

まず、`new WP_Query( $args )` をインスタンス化した瞬間、内部で何が起きているかを正確に把握する必要がある。

1. パース処理: `$args` がパースされ、デフォルト値とマージされる。
2. SQLの組み立て: `WP_SQL`（厳密にはクラスではなく各メソッド群）により、`SELECT SQL_CALC_FOUND_ROWS … FROM $wpdb.posts … WHERE …` のような巨大なSQL文が動的に生成される。
3. クエリの実行 (`$wpdb->query`): データベースに対し、実際にSQLが発行される。
4. ポストデータのキャッシング (`update_post_caches`): 取得された投稿ID群に対し、`_post_meta` や用語のターム情報が一括フェッチされ、WordPressのオブジェクトキャッシュ（`wp_cache_set`）に個別の投稿オブジェクトとして保存される。

ここで重要な事実がある。`WP_Query` 自体は、発行されたSQLの結果セット（レコードの配列やSQLの生結果）をオブジェクトキャッシュに永続化しない。 キャッシュされるのは、あくまで「取得された個々のポストオブジェクトやそのメタデータ」である。

つまり、毎回 `new WP_Query` を呼べば、複雑な JOIN や WHERE 句を持つ重いSQLは、確実にデータベースサーバーへ到達しているのだ。

—

2. オブジェクトキャッシュ層 vs データベース・クエリキャッシュの限界

「じゃあ、MySQLのクエリキャッシュ（Query Cache）に頼ればいいじゃないか」と思ったエンジニアは、現代のインフラ事情をキャッチアップし直す必要がある。

MySQL 8.0以降、クエリキャッシュ機能は完全に削除された。理由は明白で、テーブルのデータが1行でも更新されると、そのテーブルに関連するすべてのクエリキャッシュが無効化され、高負荷な環境では逆にロック競合とCPUのオーバーヘッドを激増させたからだ。

したがって、我々アプリケーション層のエンジニアが頼るべきは、WordPressのオブジェクトキャッシュ（Redis / Memcached）を活用した「結果セットのキャッシュ（Transient / Object Cache）」しかない。

しかし、ここに大きな罠がある。`WP_Query` の結果（特に投稿オブジェクトやIDの配列）をそのままキャッシュする場合、以下の2つの深刻な問題が発生する。

1. キャッシュの不整合（Stale Data）: 投稿が更新（`save_post`）された際、関連するカスタムクエリのキャッシュをパージし忘れると、古い情報がユーザーに表示され続ける。
2. シリアライゼーションのコスト: 巨大な `WP_Query` オブジェクト全体をキャッシュしようとすると、メモリ消費量が爆発し、シリアライズ／アンシリアライズの処理自体がボトルネックになる。

—

3. プロダクションコード：ID配列のキャッシングとレイジーローディングの極意

では、数百万レコード規模のデータベースにおいて、複雑なメタデータ検索を伴う `WP_Query` をどう最適化すべきか。

答えはシンプルだ。「重いSQLで取得するのは投稿ID（整数配列）のみに絞り、そのID配列をキャッシュする。そして、投稿オブジェクトの復元にはWordPressコアのキャッシュメカニズムを最大限に利用する」。

以下に、実務のコードレビューでもそのまま合格を出せる、堅牢なプロダクションコードを示す。

class Optimized_Custom_Query {

キャッシュグループ名

/
const CACHE_GROUP = ‘opt_query_group’;

キャッシュの有効期限 (1時間)

/
const CACHE_TTL = 3600;

最適化された投稿IDの取得とクエリ実行

@param array $args WP_Query用の引数
@return WP_Post[] 投稿オブジェクトの配列

/
public static function get_posts( array $args ): array {
// 1. 引数を正規化して一意なキャッシュキーを生成
$cache_key = self::generate_cache_key( $args );

// 2. オブジェクトキャッシュから「投稿IDの配列」のみを取得
$post_ids = wp_cache_get( $cache_key, self::CACHE_GROUP );

if ( false === $post_ids ) {
// キャッシュミス時の処理
// SQLの負荷を最小化するため、fields設定を ‘ids’ に強制する
$args[‘fields’] = ‘ids’;

// ページネーション不要なら no_found_rows を true にして SQL_CALC_FOUND_ROWS を排除
$args[‘no_found_rows’] = true;

$query = new \WP_Query( $args );
$post_ids = $query->posts;

// ID配列のみをキャッシュする（オブジェクト全体をキャッシュしないのが肝）
wp_cache_set( $cache_key, $post_ids, self::CACHE_GROUP, self::CACHE_TTL );

// キャッシュタグの付与（Memcached / Redisによるグループ無効化の代替・拡張用）
self::store_cache_key_reference( $cache_key, $args );
}

if ( empty( $post_ids ) ) {
return [];
}

// 3. 取得したID群に対して、WordPressコアのキャッシュ機構（update_post_caches）を一括実行
// これにより、post_metaやtermのN+1問題を完全に回避する
_prime_post_caches( $post_ids, true, true );

// 4. 順番を維持した上で、軽量に投稿オブジェクトを再構築
$posts = [];
foreach ( $post_ids as $id ) {
$post = get_post( $id );
if ( $post ) {
$posts[] = $post;
}
}

return $posts;
}

引数から一意のキャッシュキーを生成する

/
private static function generate_cache_key( array $args ): string {
// ソート順を統一してハッシュの揺れを防ぐ
ksort( $args );
return ‘opt_q_’ . md5( wp_json_encode( $args ) );
}

投稿更新時にキャッシュを安全に破棄するパージ機構

/
public static function purge_cache_on_save( int $post_id ): void {
// 自動保存やリビジョン時はスキップ
if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
return;
}

// 実際のプロダクション環境では、ここでタグベースのキャッシュ無効化や
// 該当グループのフラッシュ、またはトランジェントの削除を行う。
// 単純な実装としては wp_cache_flush_group() が利用可能（Object Cache Proなどの拡張プラグインが必要）
if ( function_exists( ‘wp_cache_flush_group’ ) ) {
wp_cache_flush_group( self::CACHE_GROUP );
} else {
// フォールバック：簡易的なグループキー管理による削除など
}
}
}

// フックの登録（投稿が更新されたらキャッシュを確実にクリア）
add_action( ‘save_post’, [ Optimized_Custom_Query::class, ‘purge_cache_on_save’ ] );
add_action( ‘deleted_post’, [ Optimized_Custom_Query::class, ‘purge_cache_on_save’ ] );

—

4. この設計が「最強」である理由（テクニカルリードからの解説）

上記のコードがなぜプロダクション品質と言えるのか、3つのポイントに集約して解説する。

① `fields => ‘ids’` によるデータ転送量の削減とインデックスの効率化

`WP_Query` でデフォルトのオブジェクトを取得しようとすると、`wp_posts` テーブルのすべてのカラム（`post_content` や `post_excerpt` などの大容量テキスト含む）がメモリにロードされる。`’fields’ => ‘ids’` を指定することで、MySQLはインデックス（通常は `PRIMARY` や `type_status_date` などの複合インデックス）の走査だけでクエリを完結させることができ（Index Coverd Queryに近づく）、ネットワーク帯域とメモリを劇的に節約できる。

② `no_found_rows => true` による `SQL_CALC_FOUND_ROWS` の排除

ページネーションの総数（`found_posts`）が不要な場合、WordPressはデフォルトでSQLに `SQL_CALC_FOUND_ROWS` を付与する。これが発行されると、MySQLはLIMIT句を無視して条件に合致するすべての行をスキャンするため、データ量が増えるにつれてクエリ速度が確実に線形悪化する。これを `true` にすることで、オプティマイザに早期リターンを促すことができる。

③ `_prime_post_caches()` によるN+1問題の完全な根絶

IDの配列さえ手に入れば、あとはWordPressコアが持つ `_prime_post_caches( $post_ids, true, true )` を呼び出すだけで、指定したID群のポストメタ（Post Meta）とタクソノミー情報をたった2回のSQLクエリ（IN句による一括取得）でオブジェクトキャッシュにプリロードできる。これにより、ループ内で動的にメタデータを呼び出しても、データベースへの追加クエリは一切発生しない。

—

結び：インフラとコードの境界線を理解せよ

真のパフォーマンスチューニングとは、「とりあえずプラグインを入れること」でも「データベースのスペックを上げること」でもない。

「データベースがどこで苦しみ、アプリケーション層がどうキャッシュをハンドリングすべきか」というデータのライフサイクルを完全にコントロールすることだ。

WP_Queryの裏側で何が行われているかを脳内でトレースし、SQLの実行回数を極限まで削ぎ落とす。このコードレビューの視点を持てば、あなたの構築するWordPressシステムは、数千万アクセスのトラフィックにもビクともしない堅牢性を手に入れるだろう。さあ、今すぐ既存の重いクエリを書き換えに行こう。