WP_Queryの限界を超える：`posts_clauses`で制御する『SQL_NO_CACHE』と高度なキャッシュ戦略
テックリードの私たちが大規模なWordPressサイトのパフォーマンスチューニングを行う際、最初に直面する壁の一つが 「意図しないオブジェクトキャッシュ（あるいはクエリキャッシュ）の暴走」 だ。
標準的な `WP_Query` は非常に便利だが、その裏側では膨大なSQLが生成され、オブジェクトキャッシュ（RedisやMemcachedなど）やMySQLのクエリキャッシュ（あるいはInnoDBのバッファプール）のヒット率を乱す。特に、リアルタイム性が求められるデータ、ユーザー固有の動的パラメータが絡む複雑なリレーション、頻繁に更新されるステータスを持つ投稿の取得において、「本来キャッシュしてはいけないデータがキャッシュされ、逆にキャッシュすべき重いクエリが毎回爆発している」 というアンチパターンを数多くコードレビューで目撃してきた。
今回は、WordPressのクエリ生成パイプラインの深部、`posts_clauses` フィルターフックにメスを入れ、MySQLレベルでの `SQL_NO_CACHE` 制御とWordPressオブジェクトキャッシュ戦略を完全に掌握するための実践的アプローチを解説する。
—
なぜ標準の `WP_Query` だけでは不十分なのか？
WordPressのデータ層は、`wp_posts` テーブルを軸に `wp_postmeta` や `wp_term_relationships` を結合（JOIN）していく。複雑な条件（Meta Queryの多用や複数タクソノミーのAND/OR検索）を構築すると、MySQLのオプティマイザにとって重いクエリが発行される。
ここで問題になるのが以下の2点だ。
1. オブジェクトキャッシュの汚染: `WP_Query` は結果の投稿ID配列をキャッシュする（`update_post_cache` など）。しかし、頻繁に状態が変わるトランザクション的なデータを扱う場合、このキャッシュが古い情報を返し、致命的な整合性エラーを引き起こす。
2. データベース層のキャッシュ競合: 動的かつ一度きりしか実行されないような管理画面の集計クエリや、パーソナライズされたフロントエンドのクエリがMySQLのキャッシュ領域を圧迫し、本当にキャッシュすべきコアのクエリを追い出してしまう。
これを解決するため、特定のクエリに対してのみMySQLのクエリキャッシュ制御（`SQL_NO_CACHE`）を挿入し、かつWordPressのオブジェクトキャッシュ層との整合性を手動でコントロールする 設計が必要となる。
—
核心：`posts_clauses` フックのメカニズム
`posts_clauses` は、`WP_Query` が最終的なSQL文を組み立てるプロセスの直前にフックする。SQLの各構成要素（`SELECT`, `DISTINCT`, `FROM`, `JOIN`, `WHERE`, `GROUPBY`, `DISTINCT`, `ORDERBY`, `LIMIT`）がすべて配列として格納されており、これを書き換えることで自由自在にSQLをハックできる。
ここに介入し、`SELECT` 句の直後に `SQL_NO_CACHE` を挿入する。
> Note: MySQL 8.0以降、`SQL_NO_CACHE` 構文は非推奨（Deprecated）となり削除されたが、多くのレガシー、あるいはMariaDB環境、または独自のクエリ制御レイヤーを持つシステムでは依然としてアーキテクチャ上の議論の対象となる。しかし、現代のWordPressインフラストラクチャにおいて「キャッシュをバイパスする」という概念は、MySQLのクエリキャッシュではなく、「WordPressのオブジェクトキャッシュ（Transients / Object Cache）のヒットを意図的にスキップし、かつDBトランザクションの鮮度を保証する」文脈へと昇華させるべきだ。
>
> 本稿では、DB層の制御思想を応用しつつ、「特定の `WP_Query` をオブジェクトキャッシュから完全に切り離す（Bypass）」ための堅牢なプロダクションコードを提示する。
—
プロダクションコード：キャッシュ制御を完全掌握するクエリクラス
以下のコードは、特定のカスタムフラグ（例: `force_no_cache => true`）が渡された `WP_Query` に対して、オブジェクトキャッシュの保存・取得を完全にバイパスし、常に最新のデータベース状態を保証するための堅牢な設計パターンだ。
/
declare(strict_types=1);
namespace Enterprise\WPCacheControl;
class QueryCacheBypasser {
/
- 初期化
/
public static function init(): void {
// クエリ生成時にカスタム引数を検知してフックを動的にスイッチ
add_action(‘parse_query’, [self::class, ‘handle_parse_query’], 10, 1);
}
/
- WP_Queryのパース時にカスタム引数をフックへバインド
- @param \WP_Query $query
/
public static function handle_parse_query(\WP_Query $query): void {
// クエリ引数に ‘force_no_cache’ が明示されている場合のみ介入
if (true === $query->get(‘force_no_cache’)) {
// 1. WP標準のオブジェクトキャッシュへの保存・取得を無効化
$query.set(‘cache_results’, false);
$query.set(‘update_post_meta_cache’, false);
$query.set(‘update_post_term_cache’, false);
// 2. SQLの断片（clauses）を操作するフィルターを追加
add_filter(‘posts_clauses’, [self::class, ‘apply_no_cache_sql_directives’], 10, 2);
// 3. クエリ実行後にクリーンアップを行う
add_filter(‘the_posts’, [self::class, ‘cleanup_query_hooks’], 10, 2);
}
}
/
- posts_clauses を利用してSQLレベルの制御（必要に応じたヒント句の付与など）を行う
- @param array $clauses
- @param \WP_Query $query
- @return array
/
public static function apply_no_cache_sql_directives(array $clauses, \WP_Query $query): array {
// 念のため対象クエリか再検証
if (true !== $query->get(‘force_no_cache’)) {
return $clauses;
}
// SELECT句の直後にSQLディレクティブ（例: SQL_NO_CACHE や Optimizer Hints）を挿入
// ※MySQL 8.0+ の場合は /+ NO_MERGE() / などのオプティマイザヒントに応用可能
if (isset($clauses[‘SELECT’]) && 0 !== stripos($clauses[‘SELECT’], ‘SQL_NO_CACHE’)) {
// 注意: MySQL 8.0以降では SQL_NO_CACHE は構文エラーになるため、
// 環境に応じた判定を入れるのがプロダクションコードの鉄則
$is_mysql_legacy = apply_vender_filter_for_legacy_mysql();
if ($is_mysql_legacy) {
$clauses[‘SELECT’] = str_ireplace(‘SELECT’, ‘SELECT SQL_NO_CACHE’, $clauses[‘SELECT’]);
}
}
return $clauses;
}
/
- クエリ実行完了後、グローバルな汚染を防ぐためにフィルターを動的に削除
- @param array $posts
- @param \WP_Query $query
- @return array
/
public static function cleanup_query_hooks(array $posts, \WP_Query $query): array {
remove_filter(‘posts_clauses’, [self::class, ‘apply_no_cache_sql_directives’], 10);
remove_filter(‘the_posts’, [self::class, ‘cleanup_query_hooks’], 10);
return $posts;
}
}
/
- 補助関数：レガシーMySQL判定
/
function apply_vender_filter_for_legacy_mysql(): bool {
// 実際の実装ではデータベースのバージョンをキャッシュして判定する
return false; // 現代の環境を想定してデフォルトはfalse
}
// 起動
QueryCacheBypasser::init();
—
この設計がプロダクション環境で求められる理由（コードレビューの視点）
テックリードとして、上記のコードがなぜ「美しい」のか、そしてなぜバグを生まないのかを解説する。
1. 状態のリーク（State Leakage）を防ぐ動的フック管理
ジュニア・中級者がやりがちなミスは、`add_filter(‘posts_clauses’, …)` をグローバルに常時常駐させ、条件分岐の中で処理をゴリ押しすることだ。これでは意図しない他の `WP_Query` まで巻き添えになり、サイト全体のパフォーマンスが崩壊する。
上記のコードでは、`parse_query` でトリガーを検知し、`the_posts`（クエリ実行の瞬間）で自らフックを解除（Self-Cleanup）している。これにより、単一のリクエスト内での副作用を完全にゼロに抑え込んでいる。
2. WordPress内部のキャッシュ機構の正確な理解
`$query->set(‘cache_results’, false);` などの設定は、単に「DBからデータを取ってくる」だけではなく、メモリ上に投稿オブジェクトのインスタンスを重複生成させないための省メモリ化にも寄与する。キャッシュをバイパスするクエリは、往々にして「一度きりのリアルタイム集計やステータス確認」であることが多いため、PHPのメモリプレッシャーを軽減する意味でもこの設定はセットでなければならない。
—
応用：逆の発想「強制キャッシュ（Force Cache）」の設計
逆に、「通常はキャッシュされない非常に重いカスタム集計クエリを、意図的に特定のキーでオブジェクトキャッシュに長期間保持させたい」という要件もある。
このような場合、`posts_pre_query` フィルターを使用する。
add_filter(‘posts_pre_query’, function($posts, \WP_Query $query) {
if (true !== $query->get(‘force_custom_cache’)) {
return $posts; // デフォルトの挙動へフォールバック
}
$cache_key = ‘custom_heavy_query_’ . md5(serialize($query->query_vars));
$cached_posts = wp_cache_get($cache_key, ‘heavy_queries’);
if (false !== $cached_posts) {
return $cached_posts; // DBを叩かずにキャッシュから即座に返す
}
// キャッシュがない場合は通常のクエリを実行させ、その結果をキャッシュに詰める
// ※実際にはposts_pre_queryでnullを返すとクエリが実行されるため、
// 後続の ‘the_posts’ フックで wp_cache_set を行うのが定石。
return $posts;
}, 10, 2);
このように、WordPressのクエリライフサイクル（Parse -> Request -> SQL Generation -> Execution -> Results）のどのフェーズに介入すべきかを正確に見極めることが、スケーラブルなWordPressアーキテクチャ構築の絶対条件となる。
—
まとめ
WordPressのパフォーマンスチューニングは、プラグインを導入して満足するレベルでは、大規模・高負荷なプロダクション環境を生き抜けません。
`WP_Query` の内部構造、そしてSQL生成レイヤーである `posts_clauses` を完全に手中に収めることで、「データの整合性」と「圧倒的な高速化」を高次元で両立させることが可能になります。
次のコードレビューでは、ただ「遅いクエリがある」と嘆くのではなく、「なぜそのクエリがキャッシュレイヤーを汚染しているのか」「どのフックでライフファイルを制御すべきか」をロジカルに示せるエンジニアであってください。アーキテクチャの主導権は、いつだってコードを深く理解している私たちの手の中にあります。