こんにちは！WordPressの裏側を支えるデータベースの仕組み、気になりますよね。普段何気なく使っている「投稿」ですが、データベースの視点から見ると、実は非常にエキサイティングな構造をしているんです。
今回は、WordPressの心臓部であるデータベーステーブル、その中でも特に重要で、パフォーマンスのボトルネックになりやすい `wp_posts` テーブルの `post_date` と `post_modified`（日付カラム） にスポットを当てます。
「日付範囲で記事を検索したいのに、サイトが重くなる…」
そんな悩みを抱えたことはありませんか？
ここをクリアすれば、あなたも単なる「WordPressの使い方を知っている人」から、内部構造まで見通せる「ワンランク上のフルスタックエンジニア」に近づけますよ。一緒にデータベースの奥深い世界を覗いてみましょう！
—
1. なぜ `wp_posts` の日付検索でサイトが重くなるのか？
まずは、WordPressのデータベースがどうなっているか、イメージしてみましょう。
`wp_posts` テーブルは、あなたのブログ記事や固定ページ、メディアなどのあらゆる「コンテンツの器」が詰まった巨大な本棚のようなものです。この本棚の中には、以下のような重要なカラム（列）が存在しています。
- `post_date`: 記事が公開された日時
- `post_modified`: 記事が最後に更新された日時
データベースの検索は「索引（インデックス）」が命
例えば、分厚い辞書の中から「WordPress」という単語を探すとき、一ページずつ最初からめくっていたら日が暮れてしまいますよね。だから辞書の巻末や冒頭には「索引（インデックス）」があります。
データベースも全く同じです。
`wp_posts` テーブルの `post_date` カラムには、デフォルトで インデックス（索引） が貼られています。そのため、「2023年10月に公開された記事を全部持ってきて！」というクエリ（命令）を投げたとき、MySQLのクエリプランナー（脳内作戦参謀のようなもの）は、インデックスを使って一瞬で該当データを見つけ出します。
陥りやすい罠：関数でカラムを包むとインデックスが死ぬ
ここで、初学者が非常によくやってしまう間違いがあります。それは、「SQLの中でカラムに日付関数を適用してしまうこと」 です。
例えば、以下のようなSQLを書いたとします。
— 【悪い例】YEAR() 関数でカラムを包んでいる
SELECT FROM wp_posts WHERE YEAR(post_date) = 2023;
一見、何が問題なの？と思いますよね。
しかし、データベースの視点に立ってみると、これは致命的です。「`post_date` そのもの」の索引を作っているのに、`YEAR(post_date)` と加工してしまうことで、データベースは「全行の `post_date` を一つずつ取り出して、年を取り出してから2023か判定する」という力技（フルスキャン）を強いられます。
結果として、インデックスが無視され、データ量が増えれば増えるほどサイトが劇的に重くなるという現象を引き起こすのです。ここ、本当にテストに出るくらい重要なポイントですよ！
—
2. クエリプランナーに愛される「正しい範囲検索」の書き方
では、どうすればインデックスを最大限に活かし、データベースを軽快に走らせることができるのでしょうか？
答えはシンプルです。「カラムを加工せず、定数（比較する値）側を加工する」こと。そして、「範囲（>= と <）で指定する」ことです。
正しいSQLの書き方（2023年の記事を効率よく取得する）
— 【良い例】カラムを加工せず、範囲でスパッと指定する
SELECT ID, post_title, post_date
FROM wp_posts
WHERE post_date >= ‘2023-01-01 00:00:00’
AND post_date < '2024-01-01 00:00:00'
AND post_status = 'publish';
この書き方であれば、クエリプランナーは `post_date` のインデックスを迷いなく選択し、2023年の境界線まで一瞬でジャンプしてデータを取得してくれます。これが、時系列クエリを高速化させる極意です。
---
3. WordPressの標準関数（WP_Query）で実践する
生のSQLを書く機会は少ないかもしれませんが、私たちが普段使うWordPressの `WP_Query` や `get_posts()` も、内部的にはこのような最適化を意識して設計されています。
PHP側で安全かつ高速に日付範囲を指定するコードを見てみましょう。
/
$args = array(
‘post_type’ => ‘post’,
‘post_status’ => ‘publish’,
‘posts_per_page’ => 10,
// date_query を使って安全かつ高速な日付範囲を指定
‘date_query’ => array(
array(
‘after’ => ‘2023-01-01 00:00:00’,
‘before’ => ‘2023-12-31 23:59:59’,
‘inclusive’ => true, // 境界値を含める
‘column’ => ‘post_date’, // wp_posts.post_date を対象にする
),
),
);
$query = new WP_Query( $args );
if ( $query->have_posts() ) {
while ( $query->have_posts() ) {
$query->the_post();
// 処理をここに記述
echo ‘
‘ . get_the_title() . ‘
‘;
}
wp_reset_postdata();
} else {
echo ‘該当する記事はありません。’;
}
コードの解説と内部の動き
- `date_query` パラメータを使用すると、WordPress内部で先ほど解説した `>=` と `<` を使った効率的なSQL文を自動生成してくれます。
- `’column’ => ‘post_modified’` に変更すれば、「2023年中に更新された記事」という条件に瞬時に切り替えることも可能です。
- WordPressコアが適切にインデックスを活用するクエリを組み立ててくれるため、私たちは安心してこのAPIを使うことができます。
—
4. さらに高度な最適化：複合インデックスという選択肢
ここから先は、数百万レコードを抱える超巨大メディアサイトを構築する際の、シークレット・ナレッジです。
WordPressのデフォルトでは、`post_date` や `post_status` にはそれぞれ単体のインデックスが貼られています。しかし、「公開ステータスが `publish` で、かつ `post_date` の新しい順に20件取得したい」という複合条件の場合、MySQLはどちらか片方のインデックスしか使えないことがあります。
もし極限までのパフォーマンスを求めるのであれば、データベース管理ツール（phpMyAdminやWP-CLIなど）を使い、以下のような複合インデックス（Composite Index）の追加を検討します。
— post_status と post_date を組み合わせた複合インデックスの作成例
ALTER TABLE wp_posts ADD INDEX idx_status_date (post_status, post_date);
このインデックスを定義しておくと、「公開済みの記事を日付順に並べる」というWordPressの最も頻繁に行われるクエリにおいて、データベースの負荷を劇的に削減することができます。
—
まとめ
今回は `wp_posts` の `post_date` と `post_modified` を軸に、時系列クエリの最適化について解説しました。
1. カラムを関数（`YEAR()`など）で包まない（インデックスが死んでしまうため）。
2. 日付検索は `>=` と `<` の範囲指定 で行う。
3. WordPressでは `date_query` を使って安全かつ高速にクエリを組み立てる。
4. 大規模サイトでは 複合インデックス の活用も視野に入れる。
ここをクリアすれば、データベースの挙動まで見通したワンランク上のWordPress開発ができるようになりますよ。ぜひ、ご自身の開発現場やプラグイン作成で活かしてみてくださいね！