WordPressの深淵：`wp_posts`のインデックス戦略と`post_status`の最適化
WordPressのパフォーマンスを語る際、多くのエンジニアは「キャッシュ」という言葉に逃げる。しかし、本当にシステムを掌握したいのであれば、最も頻繁に叩かれる `wp_posts` テーブルの物理的な振る舞いと、MySQLのクエリプランナーの思考を理解しなければならない。
今日は、`post_status` を軸としたクエリの最適化と、なぜあなたのSQLは遅いのか、その構造的な欠陥を解剖する。
—
1. `wp_posts` のインデックスの構造的限界
まず、WordPressのデフォルトのスキーマを確認してほしい。`wp_posts` には `post_status` カラムが存在するが、このカラムは単独でインデックス化されていないことがほとんどだ。
通常、`post_status` を含むインデックスは `type_status_date` のような複合インデックスとして定義される。しかし、ここで罠がある。MySQLは「カーディナリティ（値の多様性）」が低いカラムを、複合インデックスの先頭に置くことを嫌う。
`publish` や `inherit` は膨大に存在するが、`future` や `pending` は極めて少ない。この偏りが、クエリプランナーを迷わせる。
なぜ `post_status` だけで検索してはいけないのか
`SELECT FROM wp_posts WHERE post_status = ‘publish’` を発行すると、MySQLは「全行走査（Full Table Scan）」を選択するか、運が良ければ他のインデックスを無理やり使おうとしてコストを増大させる。
—
2. 堅牢なインデックス戦略：複合インデックスの再定義
クエリを最適化するための第一歩は、`post_status` を単独で扱うのではなく、頻出するクエリの「検索条件の組み合わせ」を物理層に反映させることだ。
推奨されるインデックス設計（コンポジット）
もし、あなたが「公開済み（publish）」の「投稿タイプ（post）」を「日付順」に取得するAPIを多用するなら、以下のインデックスが必須となる。
— 推奨インデックス: post_type + post_status + post_date
CREATE INDEX idx_type_status_date ON wp_posts (post_type, post_status, post_date);
理由：
1. 検索の絞り込み: `post_type` でまず範囲を絞り、次に `post_status` でフィルタリングを行う。
2. ソートの回避: `post_date` がインデックスに含まれているため、MySQLはFilesort（メモリ内でのソート）を行わず、インデックスの順序をそのまま利用できる。
—
3. 実践：WordPressクエリを強制的に最適化する
`WP_Query` を使う際、単に `post_status => ‘publish’` と書くだけでは不十分なケースがある。特に大規模データセットでは、`no_found_rows` を活用し、SQLの計算コストを削ぎ落とす必要がある。
プロダクションコード例
以下のコードは、パフォーマンスと保守性を両立させた設計パターンだ。
/
- 高速なコンテンツ取得のためのクエリ設計
- 内部でSQL_CALC_FOUND_ROWS（COUNT()）を無効化し、クエリプランナーへの負荷を軽減
/
function get_optimized_posts(string $status = ‘publish’): array {
$args = [
‘post_type’ => ‘post’,
‘post_status’ => $status,
‘posts_per_page’ => 10,
// ここが重要：ページネーションが不要なら絶対に入れること
‘no_found_rows’ => true,
// キャッシュ戦略：クエリをシリアライズさせず、直接結果をキャッシュする
‘update_post_meta_cache’ => false,
‘update_post_term_cache’ => false,
];
$query = new WP_Query($args);
return $query->posts;
}
—
4. ステータス遷移の設計：バグを生むな
「公開」から「予約投稿」への遷移時、あるいはその逆のタイミングで、データベースの整合性が崩れるケースが多い。WordPressのコアは `wp_transition_post_status` フックを提供しているが、これを使うだけでは不十分だ。
テクニカルリードからの助言:
ステータス遷移時には、必ず `post_date_gmt` との整合性を検証せよ。
add_action(‘transition_post_status’, function($new_status, $old_status, $post) {
// 予約投稿への遷移時に、日付が未来であることを保証するロジック
if ($new_status === ‘future’) {
if (strtotime($post->post_date_gmt) <= time()) {
// ここでステータスを強制的に'publish'へ戻すか、例外を投げる
// 整合性のとれないステータスは、インデックスを無駄に汚染する
error_log("Invalid status transition detected for post ID: {$post->ID}”);
}
}
}, 10, 3);
—
結びに：エンジニアとしての矜持
WordPressは「誰でも使える」システムだが、「誰でも高速に動かせる」システムではない。
1. インデックスの順序はデータ量とクエリの頻度で決める。
2. `no_found_rows` を忘れることは、罪に近い。
3. ステータス遷移の整合性は、アプリケーション層のフックで厳格にガードする。
この3点を守るだけで、あなたのシステムは一般的なWordPressサイトとは一線を画す安定性を手に入れるはずだ。さあ、今すぐ `EXPLAIN` を叩いて、自分の書いたクエリがどこで躓いているか確認してほしい。それが真のエンジニアの第一歩だ。