WordPressの深淵を覗く：`wp_posts`のインデックス設計と`post_status`の最適化戦略
WordPressのパフォーマンスチューニングにおいて、`wp_posts`テーブルは避けて通れない最大のボトルネックである。特に数百万件規模のデータセットを扱う場合、安易なクエリ設計はDBサーバーのCPUスパイクを招き、システム全体を停止させるリスクを孕んでいる。
今回は、多くのエンジニアが見過ごしている「`post_status`によるクエリ絞り込み」と「インデックスの選択性」について、コアの内部構造から紐解いていく。
—
1. なぜ `post_status` がクエリの命運を分けるのか
WordPressのデフォルトのインデックスは、`wp_posts`テーブルにおいて以下のように定義されている。
KEY “type_status_date” (“post_type”, “post_status”, “post_date”, “ID”)
ここで重要なのは、「インデックスのカーディナリティ（選択性）」だ。
もしあなたのアプリケーションが『公開済み（`publish`）』の記事を高速に取得することに特化している一方で、DB内に『下書き（`draft`）』や『自動保存（`auto-draft`）』が大量に蓄積されている場合、このインデックスは非常に非効率に働く。
MySQLのオプティマイザは、検索対象のデータの割合が一定（通常20〜30%）を超えると、インデックスを使わずにフルテーブルスキャン（全件走査）を選択する。`post_status`のようなカーディナリティの低いカラムでインデックスの先頭を占有させると、MySQLは「インデックスを使うよりも全件読んだ方が速い」と判断し、結果としてパフォーマンスが壊滅するのだ。
—
2. 堅牢な設計：カスタムテーブルか、ステータスの分離か
もし、特定のステータスを持つデータに対して頻繁に複雑なクエリを投げる必要がある場合、`wp_posts`をそのまま叩き続けるのは悪手である。以下の設計パターンを推奨する。
戦略A：`wp_postmeta` をインデックス化する（非推奨）
`postmeta`に`_status`をメタデータとして保存し直す手法は、JOINコストが増大するため、パフォーマンス面では最悪の選択肢となる。
戦略B：専用のサロゲートテーブル（推奨）
高頻度でアクセスされるステータス（例：`active`な案件データのみ等）については、専用の軽量テーブルを用意し、`wp_posts`とIDで同期させる設計が最も堅牢だ。
—
3. 実践：クエリのコストを最小化する最適化コード
では、既存の`WP_Query`や`get_posts`を最大限に活かしつつ、インデックスを有効活用するための「美しい」実装を紹介する。
非効率な例（なぜダメなのか）
// NG: 複数のステータスを指定すると、インデックスの絞り込みが弱まる
$posts = get_posts([
‘post_type’ => ‘project’,
‘post_status’ => [‘publish’, ‘private’, ‘future’], // ここがボトルネック
]);
推奨される実装：インデックスヒット率を最大化するアプローチ
特定のステータスで絞り込む場合、`posts_where`フックを使用して、インデックスの順序と一致するクエリを強制する。
/
- 特定のpost_statusに特化した最適化クエリ
- インデックス: (post_type, post_status, post_date) を有効活用する
/
add_filter(‘posts_clauses’, function($clauses, $query) {
global $wpdb;
// 特定のクエリのみに適用するガード節
if (!$query->get(‘optimize_status_index’)) {
return $clauses;
}
// WHERE句をインデックスの順序に合わせて最適化
// 必要に応じて、不要なステータスチェックを除外する
$clauses[‘where’] = str_replace(
“{$wpdb->posts}.post_status IN (‘publish’, ‘future’)”,
“{$wpdb->posts}.post_status = ‘publish'”,
$clauses[‘where’]
);
return $clauses;
}, 10, 2);
// 呼び出し側
$posts = new WP_Query([
‘post_type’ => ‘project’,
‘post_status’ => ‘publish’, // 単一ステータスに絞ることでインデックスの選択性を高める
‘optimize_status_index’ => true,
]);
—
4. テクニカルリードからの提言：運用の鉄則
1. `auto-draft` を掃除せよ:
WPコアは、記事編集画面を開くたびに`auto-draft`を生成する。数万件のゴミデータはインデックスの統計情報を狂わせる。`wp_delete_post_on_trash`などのフックを使い、期限切れの不要なステータスレコードは物理削除する運用を徹底すること。
2. EXPLAINを読め:
自分の書いたコードが、実際にMySQLでどう実行されているかを知らないエンジニアに最適化を語る資格はない。`SAVEQUERIES`を一時的に有効にし、`EXPLAIN SELECT …` を実行して `type` が `ref` または `const` になっているか確認すること。`ALL`（全件走査）が表示されたら、その瞬間に設計を見直すべきだ。
3. キャッシュ戦略:
データベースへのクエリは、可能な限り `wp_cache_get` でオブジェクトキャッシュ（Redis等）を介すること。`post_status`で絞り込んだ結果セットそのものをキーにしてキャッシュすることで、DBへの負荷をゼロに近づけられる。
WordPressを「ただのブログツール」と見なすか、「堅牢なRDBMS基盤」と見なすか。その差は、こうしたインデックス一つに対する執着心に表れる。設計の段階で、常にDBの物理層を意識したコードを書いてほしい。それが、プロフェッショナルとしての最低限の流儀だ。