こんにちは。WordPressの深淵へようこそ。
WordPressを単なる「ブログツール」だと思っていませんか？実はこれ、内部構造を理解すれば、数百万レコードを扱う大規模データプラットフォームにもなり得る強力なCMSなんです。
今日は、WordPressの心臓部であるデータベース、特に `wp_posts` テーブルの「時間軸」に焦点を当てて、エンジニアとして確実にステップアップするための話をしましょう。ここを制する者は、WordPressのパフォーマンスを制します。
—
1. なぜ `wp_posts` の日付カラムが重要なのか
`wp_posts` テーブルには、投稿データが詰まっています。そして、最も頻繁にクエリされるのが `post_date` と `post_modified` です。
- `post_date`: 記事の公開日時。時系列での記事抽出（最新記事一覧など）に使われます。
- `post_modified`: 記事の最終更新日時。キャッシュの有効期限判定や、更新順のソートに使われます。
これらは単なる日付データではなく、データベースの「検索の鍵（インデックス）」として機能します。しかし、SQLの書き方を間違えると、インデックスが無視され、MySQLが全行を舐める「フルテーブルスキャン」が発生します。これがサイトが重くなる最大の原因です。
—
2. 物理構造とインデックスの可視化
WordPressをインストールした直後の状態では、`post_date` にはインデックスが貼られていますが、`post_modified` はデフォルトでは貼られていません。
図解すると、こんなイメージです。
[ wp_posts テーブル ]
+—-+————-+———————+———————+
| ID | post_title | post_date (Indexed) | post_modified |
+—-+————-+———————+———————+
| 1 | Hello World | 2023-01-01 10:00:00 | 2023-01-01 10:00:00 |
| 2 | Tips | 2023-01-02 12:00:00 | 2023-05-01 09:00:00 |
…
ここで `post_modified` を元にソートしようとすると、MySQLは「インデックスがないから、全件見てから並び替えなきゃ…」となります。データが1万件を超えた瞬間、表示速度は目に見えて低下します。
陥りやすいミス：関数を使った検索
例えば、WP_Queryで以下のようなことをしていませんか？
// 悪い例：日付から「年」だけを抽出して比較している
$args = array(
‘date_query’ => array(
array(
‘column’ => ‘post_modified’,
‘compare’ => ‘>=’,
‘value’ => ‘2023-01-01’
),
),
);
これはまだマシですが、SQL内部で `YEAR(post_modified) = 2023` のように関数を通すと、インデックスは完全に無効化されます。 日付範囲（Range）で指定するのが、データベース最適化の鉄則です。
—
3. EXPLAINで「実行計画」を覗き見る
プロのエンジニアは、勘でコードを書きません。SQLがどう動くかを検証します。MySQLの `EXPLAIN` コマンドを使いましょう。
EXPLAIN SELECT FROM wp_posts WHERE post_date > ‘2023-01-01’;
実行結果の `type` カラムを見てください。
- `ALL`: 全件走査（最悪です）
- `range`: インデックスを使った範囲検索（合格ライン）
- `const`: インデックスによるピンポイント検索（最高！）
もし `type` が `ALL` になっていたら、そのクエリはサイトの足を引っ張っています。すぐにインデックスの追加を検討するか、クエリの条件を見直しましょう。
—
4. 実戦的最適化：WP_Queryをスマートに書く
WordPressで最も効率的にデータを取得するコード例を紹介します。ポイントは「不要なフィールドを取得しないこと」です。
$args = [
‘post_type’ => ‘post’,
‘posts_per_page’ => 10,
‘orderby’ => ‘modified’, // post_modified を基準にする
‘order’ => ‘DESC’,
‘fields’ => ‘ids’, // 記事データ全体ではなく ID だけ取得する（メモリ節約！）
‘no_found_rows’ => true, // ページネーション不要ならこれをONにする（SQLが劇的に軽くなる）
];
$query = new WP_Query($args);
ここがプロの視点：
- `fields => ‘ids’`: 記事の本文（post_content）などは巨大です。一覧表示で不要なら、IDだけ取得して後で必要な分だけキャッシュから取り出すのが、大規模サイトの基本戦略です。
- `no_found_rows => true`: これを忘れると、WordPressはわざわざ全件のカウント（`SELECT SQL_CALC_FOUND_ROWS`）を行います。これが大規模サイトでは致命的な遅延を生みます。
—
最後に：WordPressを掌握するために
「なぜこのクエリは遅いのか？」と疑い、`EXPLAIN` を叩き、インデックスの仕組みを理解する。このプロセスこそが、WordPressエンジニアとして一段上のステージに上がるための鍵です。
最初は難しく感じるかもしれませんが、一度「データベースの物理層」が見えるようになると、どんなに重いWordPressサイトでも魔法のように高速化できるようになります。
ここをクリアすれば、あなたはもうただの「利用者」ではありません。WordPressの内部を自在に操る「設計者」です。次はキャッシュレイヤーの話でお会いしましょう。質問があればいつでもどうぞ！