WP_Queryの `date_query` はなぜデータベースを殺すのか：インデックススキャンを死守する極限の低レイヤ最適化
WordPressの柔軟性を支える `WP_Query` は、抽象化の代償として、しばしばデータベースレイヤにおいて致命的なパフォーマンス劣化を引き起こす。
特に `date_query` を用いた日付範囲の絞り込みは、MySQL/MariaDBのクエリプランナーを欺き、インデックスを無視したフルテーブルスキャン（全表走査）を誘発する温床となる。
本稿では、`WP_Query` が発行するSQLの内部挙動を解剖し、ストレージエンジン（InnoDB）のB-treeインデックス構造とオプティマイザの挙動を踏まえた上で、ミリ秒単位の応答速度を死守するためのインデックス設計とクエリチューニングの極限を解説する。
—
1. `date_query` の罪：なぜインデックススキャンが破綻するのか
中級エンジニアが陥る最初の罠は、「`wp_posts` テーブルの `post_date` カラムにはデフォルトでインデックス（`type_status_date` や単体インデックス）があるから安心だ」という誤認である。
しかし、`WP_Query` に以下のような `date_query` を渡した瞬間、MySQLのオプティマイザはインデックスの放棄を余儀なくされる。
$args = array(
‘post_type’ => ‘post’,
‘date_query’ => array(
array(
‘after’ => ‘2023-01-01’,
‘before’ => ‘2023-12-31’,
‘inclusive’ => true,
),
),
);
$query = new WP_Query( $args );
発行されるSQLの暗部
上記のクエリが生成するSQLのWHERE句を抽出し、EXPLAIN解析を行うと、以下のような醜態が露呈する。
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
WHERE 1=1
AND (
(wp_posts.post_date >= ‘2023-01-01 00:00:00’ AND wp_posts.post_date <= '2023-12-31 23:59:59')
)
AND wp_posts.post_type = 'post'
AND (wp_posts.post_status = 'publish' ...)
一見、何の問題もない範囲検索（Range Scan）に見える。だが、ここには深刻な構造的欠陥がある。
WordPressのデフォルトインデックスは多くの場合、複合インデックス（例: `post_status`, `post_date`, `post_type` の順など、MySQLのバージョンやスキーマ履歴に依存）で構成されている。
さらに、`SQL_CALC_FOUND_ROWS` の存在がクエリキャッシュやインデックスの効き目を完全に破壊する。MySQLは条件に合致するすべての行をスキャンしてカウントを計算し直すため、インデックスのB-treeを逆順にたどるような非効率なアクセスパスが選択されやすい。データ量が千万規模に達すると、このクエリ単体でCPU使用率が100%に張り付く。
---
2. InnoDBのB-treeと「関数・型の不一致」によるインデックス無効化
さらに深部を見ていこう。開発者が無意識に記述するカスタムの `date_query` や、メタデータ（`post_meta`）を絡めた日付比較では、カラムに対する暗黙の型変換（Implicit Type Conversion） や 関数ラップ が発生する。
MySQLのインデックスは、カラムの生データがB-tree上にソートされて格納されているからこそ機能する。WHERE句で以下のような演算が行われた瞬間、インデックスは「ただの重い飾り」と化す。
- カラムに対してDATE()やYEAR()などの関数を適用する
- 異なる文字コード・照合順序（Collation）の比較を行う
- 浮動小数点や文字列型への暗黙のキャスト
`WP_Query` 自体は適切にプリペアドーステートメント（`$wpdb->prepare`）を使用しているためSQLインジェクションの懸念はないが、「意図したインデックスが使われているか（Key_len と Rows の値）」 をスロークエリログや `EXPLAIN` で常時監視していなければ、システムは静かに崩壊に向かう。
—
3. 対策：複合インデックスの再設計と `WP_Query` のフック制御
ここからが本題だ。データベースのスキーマ構造に手を入れられないSaaS環境や、極限までパフォーマンスを絞り出す必要があるエンタープライズ環境において、どのようにこのボトルネックを突破するか。
A. カバリングインデックス（Covering Index）の最適化
もし独自にデータベースのマイグレーションが許可されているならば、検索クエリの「WHERE句の絞り込み」と「ORDER BY」を完全にカバーする複合インデックスを明示的に張るべきである。
— post_type, post_status, post_date の順序が極めて重要
CREATE INDEX idx_optimized_date_query
ON wp_posts (post_type, post_status, post_date);
この順序（Leftmost Prefix原則）により、`post_type` と `post_status` で完全に絞り込まれたピンポイントのリーフノード群に対してのみ、`post_date` のB-tree範囲検索がO(log N)のオーダーで炸裂する。
B. `posts_clauses` フィルターによる `SQL_CALC_FOUND_ROWS` の排除とクエリの直叩き
WordPress 5.3以降、`SQL_CALC_FOUND_ROWS` のパフォーマンス悪化が問題視され、コア側でも最適化が進められているが、依然として `WP_Query` はデフォルトでこれを有効化しがちである。
ページネーションの総数（`found_posts`）が厳密に必要ない、あるいは無限スクロール等の実装であれば、この不要な重処理をフックで強制排除する。
以下のコードは、`date_query` を利用しつつ、データベースへの負荷を最小限に抑えるための極限チューニングコードである。
/
- WP_Queryの内部挙動をハックし、不要なSQL_CALC_FOUND_ROWSを排除して
- インデックススキャン効率を極限まで高める設計パターン
/
function optimize_date_query_performance( $clauses, $wp_query ) {
global $wpdb;
// 特定のカスタムクエリ、あるいはメインクエリの特定条件でのみ発動させるガード
if ( ! $wp_query->get( ‘optimized_date_range_search’ ) ) {
return $clauses;
}
// SQL_CALC_FOUND_ROWS を SELECT 句からパージする
// これによりMySQLは全件カウントの呪縛から解放される
$clauses[‘fields’] = preg_replace( ‘/^SELECT\s+SQL_CALC_FOUND_ROWS\s+/’, ‘SELECT ‘, $clauses[‘fields’] );
return $clauses;
}
add_filter( ‘posts_clauses’, ‘optimize_date_query_performance’, 10, 2 );
/
- 実行側の実装例
/
$optimized_query = new WP_Query( array(
‘post_type’ => ‘event’,
‘post_status’ => ‘publish’,
‘posts_per_page’ => 20,
‘optimized_date_range_search’ => true, // 独自フラグでフックを制御
‘date_query’ => array(
array(
‘after’ => ‘2023-01-01 00:00:00’,
‘before’ => ‘2023-12-31 23:59:59’,
‘inclusive’ => true,
‘column’ => ‘post_date’,
),
),
// ページネーションの総数計算を無効化し、クエリコストを劇的に削減
‘no_found_rows’ => true,
));
—
4. 仮想マシン/ランタイムレベルでの最終防衛線：オブジェクトキャッシュとTransient
どれほどSQLとインデックスを最適化しようとも、秒間数千リクエストを受ける高トラフィック環境において、リレーショナルデータベースへの物理アクセスはそれ自体がスケーラビリティのボトルネックとなる。
シニアエンジニアとして到達すべき最終防衛ラインは、「クエリすら発行させないこと」 である。
1. Memcached / Redis による永続的オブジェクトキャッシュ（Persistent Object Cache）の導入
`WP_Query` の結果（ポストIDの配列）をキャッシュバックエンドに載せることで、データベースのB-treeトラバーサル自体を完全にバイパスする。
2. 日付範囲クエリのキー正規化
`date_query` のパラメータをシリアライズしたハッシュ値を生成し、それをキャッシュキーのプレフィックスとして利用する。
$cache_key = ‘evt_date_q_’ . md5( serialize( $args ) );
$post_ids = wp_cache_get( $cache_key, ‘custom_date_queries’ );
if ( false === $post_ids ) {
$query = new WP_Query( $args );
$post_ids = $query->posts;
// 有効期限（TTL）をトラフィック量に応じて動的に制御
wp_cache_set( $cache_key, $post_ids, ‘custom_date_queries’, 3600 );
}
結言
WordPressの `WP_Query` は強力な抽象化レイヤであるがゆえに、内部で何が起きているかをブラックボックス化しやすい。
しかし、データベースの物理構造（InnoDB、B-tree、インデックスの順序）、オプティマイザの挙動、そしてランタイムのメモリ管理まで見通す視点を持つならば、WordPressはエンタープライズの負荷にも耐えうる堅牢なシステムへと昇華する。
「動くコード」を書く段階を脱し、インフラストラクチャの限界領域をコントロールするエンジニアであれ。インデックスの選択権をMySQLに委ねるな。自らの手で、実行計画（Execution Plan）を完全に支配せよ。