こんにちは！WordPressの裏側の仕組みまで完全に理解して、どんな大規模サイトでも高速に動かせるエンジニアを目指していますか？
今回は、実務で本当によく使われるけれど、実はデータベースのパフォーマンスを大きく左右する「`WP_Query`の`date_query`」について解説していきますね。
「他の言語やフレームワークは分かるけれど、WordPressのデータベース周りはブラックボックスっぽくて少し怖い……」そんな風に感じている方もご安心ください。ここをクリアすれば、WordPressのデータ処理の本質がぐっと見えてきますよ。一緒に基本から深く掘り下げていきましょう！
—
なぜ `date_query` はパフォーマンスのボトルネックになりやすいのか？
WordPressの投稿データは、主に `wp_posts` という巨大なテーブルに保存されています。投稿日（`post_date`）や修正日（`post_modified`）でデータを絞り込むとき、私たちはよく `WP_Query` の `date_query` を使いますよね。
例えば、「直近1週間以内に公開された特定のカスタム投稿のデータを取得したい」と思ったとき、こんなコードを書くはずです。
$args = array(
‘post_type’ => ‘event’,
‘posts_per_page’ => 10,
‘date_query’ => array(
array(
‘after’ => ‘1 week ago’,
‘inclusive’ => true,
),
),
);
$query = new WP_Query( $args );
一見、とてもシンプルで直感的なコードですよね。しかし、裏側でMySQLが何をしているのかを知らないと、データベースのCPU使用率が跳ね上がり、サイト全体が重くなる原因を作ってしまいます。
データベースの視点から見た「範囲検索」の罠
ここで、MySQLが裏側で実行しているSQLのイメージを覗いてみましょう。`date_query` は内部的に次のようなSQL文を組み立てます。
SELECT FROM wp_posts
WHERE post_type = ‘event’
AND post_status = ‘publish’
AND post_date >= ‘2023-10-01 00:00:00’;
ここでプログラミング初心者が陥りがちなのが、「インデックス（索引）があるから高速に検索できるはず」という思い込みです。
もちろん、`wp_posts` テーブルの `post_date` カラムにはデフォルトでインデックスが貼られています。しかし、`post_type` や `post_status` と組み合わせた複合的な検索条件になったとき、MySQLのオプティマイザー（実行計画を立てる頭脳）がどのインデックスをどう使うべきか迷ってしまうことがあります。
特に、次のような書き方をするとインデックスがうまく効かなくなる（これを「インデックスのスキャン効率低下」や「フルテーブルスキャン」と呼びます）ため注意が必要です。
—
陥りがちな文法エラー・アンチパターン
まずは、実務でやりがちな「実はパフォーマンスを落としている書き方」を確認しておきましょう。
1. タイムゾーンやフォーマットの不一致による関数ラップ
`date_query` の中で複雑な条件を指定しすぎたり、データベース側で関数（`YEAR()` や `DATE()` など）を通すようなクエリを強制させたりすると、インデックスが無効化されてしまいます。
2. 不要な `meta_query` との組み合わせ
日付の範囲と、カスタムフィールド（`meta_query`）の条件を同時に、かつ複雑に組み合わせると、MySQLは一時的な仮想テーブル（Filesort）を作成し始め、メモリを大量消費します。
// ⚠️ 注意：この組み合わせはデータ量が増えると危険な香りがします
$args = array(
‘post_type’ => ‘event’,
‘date_query’ => array(
array( ‘after’ => ‘2023-01-01’ ),
),
‘meta_query’ => array(
array(
‘key’ => ‘event_price’,
‘value’ => 1000,
‘compare’ => ‘>’,
),
),
);
メタデータ（`wp_postmeta`）は別テーブルに存在するため、`JOIN` が発生します。そこに `date_query` の範囲検索が絡むと、MySQLの実行計画は非常に複雑になり、インデックスが十分に機能しなくなるケースがあるのです。
—
MySQLの「実行計画（EXPLAIN）」でボトルネックを暴く
では、私たちが書いた `WP_Query` がデータベース上でどのように処理されているかを確認するにはどうすればよいでしょうか？
ここで登場するのが、MySQLの強力な機能 `EXPLAIN` です。
開発環境で、実際に発行されたSQLの先頭に `EXPLAIN` をつけて実行してみます。
EXPLAIN SELECT FROM wp_posts WHERE post_type = ‘event’ AND post_date >= ‘2023-10-01 00:00:00’;
この結果（実行計画）の中で、特に注目すべきポイントは以下の2つです。
1. `type` カラム
- `ALL` と表示された場合：「フルテーブルスキャン」を意味します。テーブル全体のデータを1行ずつ舐めて確認しているため、データが増えると比例して遅くなります（危険信号！）。
- `range` や `ref` と表示された場合：インデックスを活用して効率的に絞り込んでいます（理想的！）。
2. `key` カラム
- MySQLが実際にどのインデックスを使用しているかが表示されます（例：`post_date` や複合インデックス名）。ここが `NULL` になっている場合、インデックスが使われていません。
—
インデックスを最適化し、爆速化するための実務テクニック
「じゃあ、どうやって最適化すればいいの？」という疑問にお答えします。実務で使える具体的なアプローチを3つ紹介しますね。
1. 複合インデックス（Composite Index）の活用
単一の `post_date` だけでなく、頻繁に検索条件としてセットで使われるカラム（例：`post_type` と `post_date`）の組み合わせに対して、データベース側で複合インデックスを追加します。
phpMyAdminやデータベースクライアントから、次のようなインデックスを追加してみてください。
— post_type と post_date を組み合わせた複合インデックスの作成例
ALTER TABLE wp_posts ADD INDEX post_type_date_idx (post_type, post_date);
このように、「絞り込み条件（=`）」を先に置き、「範囲検索条件（>= など）」を後ろに配置した複合インデックスを作ることで、MySQLは一瞬で該当データにたどり着けるようになります。
2. `WP_Query` のパラメータを軽量化する
日付の範囲検索を行う際、デフォルトでは該当する投稿の「すべてのデータ（本文やスラッグなど含む）」がメモリにロードされます。もしIDや日付だけが必要な場合は、必ず次のパラメータを追加してクエリを軽量化しましょう。
$args = array(
‘post_type’ => ‘event’,
‘posts_per_page’ => 20,
‘fields’ => ‘ids’, // 投稿IDの配列だけを取得し、データ量を極限まで減らす！
‘date_query’ => array(
array(
‘after’ => ‘2023-10-01’,
‘inclusive’ => true,
),
),
);
$query = new WP_Query( $args );
`’fields’ => ‘ids’` を指定するだけで、不要なカラムのフェッチがなくなり、データベースの負荷が劇的に下がります。
3. キャッシュ戦略と組み合わせる
どれだけデータベースのインデックスを最適化しても、アクセスが集中するトップページやアーカイブページで毎回クエリを走らせるのは得策ではありません。
Transient APIやオブジェクトキャッシュ（Redis / Memcachedなど）を組み合わせ、`WP_Query` の結果自体をキャッシュする仕組みを必ずワンセットで実装しましょう。
—
まとめ：ここをクリアすればWordPressの基本はバッチリ！
今回は、`WP_Query` の `date_query` を切り口に、データベースのインデックスとパフォーマンス最適化の世界を覗いてみました。
- `date_query` は便利だが、条件によってはフルテーブルスキャンになりがち
- MySQLの `EXPLAIN` を使って、インデックスが効いているか（`type` が `range` になっているか）を確認する
- 必要に応じて複合インデックスを作成し、`’fields’ => ‘ids’` などでクエリ自体を軽量化する
このあたりのデータベースの挙動まで意識してコードが書けるようになると、あなたはもう「初学者」のステージを完全に卒業し、信頼される中級・上級エンジニアの仲間入りです。
パフォーマンスに配慮した美しいコードで、サクサク動く快適なWordPressサイトを構築していきましょう！応援しています。