序文：抽象化の代償と、物理層への回帰
WordPressというエコシステムがこれほどまでに巨大化した要因の一つは、`wp_posts`という極めて抽象度の高いエンティティ設計にある。しかし、この「何でも入る」という柔軟性は、データベース層においては諸刃の剣だ。
多くのエンジニアは`WP_Query`を叩き、生成されるSQLを眺めて満足する。だが、数百万レコードを超える大規模な基盤において、標準のインデックス設計はあまりに無力だ。特に、`post_type`と`post_status`という、一見するとカーディナリティ（値の多様性）の低いカラムの組み合わせが、クエリプランナーを惑わせ、致命的なフルテーブルスキャンや非効率なインデックスマージを引き起こす。
本稿では、InnoDBストレージエンジンのB+Tree構造にまで踏み込み、`wp_posts`における複合インデックスの最適解と、クエリプランナーを完全に制御するための戦略を詳説する。
—
1. 統計情報の嘘とカーディナリティの罠
MySQLのクエリプランナー（オプティマイザ）は、コストベースで実行計画を決定する。ここで重要なのは、`post_type`や`post_status`単体では「選択性（Selectivity）」が極めて低いという事実だ。
例えば、`post_type = ‘post’` かつ `post_status = ‘publish’` という条件は、ブログサイトにおいては全データの9割以上に該当する場合がある。
この時、オプティマイザは「インデックスを辿ってランダムI/Oを繰り返すよりも、先頭から順にフルスキャン（Seq Scan）したほうが速い」と判断する。これが、インデックスが「貼ってあるのに効かない」現象の正体だ。
物理構造の視点：B+Treeの深淵
InnoDBにおいて、セカンダリインデックスは主キー（`ID`）へのポインタを保持している。
1. インデックスをスキャンする。
2. 合致した`ID`を取得する。
3. クラスタードインデックス（データ本体）へ「ブックマークルックアップ」を行う。
この3のコストが膨大になるため、カーディナリティの低いカラムへの単一インデックスは、大規模環境ではノイズでしかない。
—
2. 複合インデックスの設計理論：(Type, Status, Date) の三位一体
クエリプランナーに最適な経路を選択させるためには、等価比較（=）されるカラムを先頭に、範囲比較（<, >, BETWEEN）されるカラムを後方に配置するのが鉄則である。
WordPressの典型的なクエリ（最新記事一覧など）を想定した場合、以下の複合インデックスが究極の解となる。
— 既存のインデックスでは不十分だ。物理構造を再定義する。
ALTER TABLE wp_posts ADD INDEX idx_type_status_date (post_type, post_status, post_date, ID);
なぜこの順番なのか？
1. `post_type`: 最初のフィルタリング。通常、クエリでリテラル指定される。
2. `post_status`: 2番目のフィルタリング。これもリテラル指定（’publish’等）が多い。
3. `post_date`: 範囲検索。ソート（ORDER BY）に使用される。
4. `ID`: カバリングインデックス（Covering Index）化のため。
この順序でインデックスを構成することで、MySQLはインデックスの特定の範囲（Range）を特定し、そのままの順序でデータを取得できる。`ORDER BY post_date DESC` が発生しても、インデックス自体がその順序でソートされているため、Filesort（メモリ上での再ソート）を完全に回避できるのだ。
—
3. 実践：クエリプランナーを掌握する
実際にこのインデックスがどう機能するか、`EXPLAIN`を用いて解析しよう。
非効率なクエリの例
標準のインデックスしかない場合、`post_type`単体、あるいは`post_status`単体のインデックスが使われるか、最悪の場合はフルスキャンが発生する。
— 実行計画を確認
EXPLAIN SELECT ID FROM wp_posts
WHERE post_type = ‘post’
AND post_status = ‘publish’
ORDER BY post_date DESC LIMIT 10;
複合インデックス適用後の挙動
前述の `idx_type_status_date` を適用すると、`Extra` フィールドに `Using index` が表示されるはずだ。これはデータファイルを見に行かず、インデックスノード内のデータだけでクエリを完結させたことを意味する。
+—-+————-+———-+——-+———————–+———————-+———+——+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+———-+——-+———————–+———————-+———+——+——+————-+
| 1 | SIMPLE | wp_posts | range | idx_type_status_date | idx_type_status_date | 162 | NULL | 10 | Using index |
+—-+————-+———-+——-+———————–+———————-+———+——+——+————-+
この `key_len` の変化と `Using index` の出現こそが、DBエンジニアが勝利を確信する瞬間である。
—
4. WordPressコアへの実装：フックによる最適化
WordPressの`WP_Query`は非常に優秀だが、時として意図しないインデックスを選択させることがある。また、DB構造の変更をプラグインやテーマから制御する場合は、`dbDelta` よりも直接的なDDL発行が必要になるケースが多い。
以下は、この最適化をシステムに組み込むための高度な実装例だ。
/
final class WP_Database_Optimizer {
private const INDEX_NAME = ‘idx_type_status_date_optimized’;
public static function apply_optimized_index() {
global $wpdb;
// 既にインデックスが存在するか確認
$index_exists = $wpdb->get_results( $wpdb->prepare(
“SHOW INDEX FROM {$wpdb->posts} WHERE Key_name = %s”,
self::INDEX_NAME
) );
if ( empty( $index_exists ) ) {
// 複合インデックスの作成
// post_type(20), post_status(20) はデータ長を考慮してプレフィックスを指定する場合もあるが、
// 完全一致を狙うため、カラム全体をカバーするのが定石。
$wpdb->query(
“ALTER TABLE {$wpdb->posts}
ADD INDEX ” . self::INDEX_NAME . ” (post_type, post_status, post_date, ID)”
);
}
}
/
- 特定の複雑なクエリにおいて、強制的にインデックスを指定する（FORCE INDEX）
- ※基本的にはオプティマイザを信じるべきだが、統計情報のブレを許容できない極限環境で使用。
/
public static function force_index_hint( $groupby, $query ) {
global $wpdb;
if ( strpos( $query->request, “post_type = ‘post'” ) !== false ) {
return ” FORCE INDEX (” . self::INDEX_NAME . “) “;
}
return $groupby;
}
}
// 実行（実際にはアクティベーションフックなどで呼ぶべき）
// WP_Database_Optimizer::apply_optimized_index();
—
5. メモリ最適化とバッファプールの戦略
インデックスを設計するだけでは不十分だ。物理メモリへの収まり（Memory Residency）を考慮しなければならない。
InnoDBの `innodb_buffer_pool_size` に、この複合インデックスのリーフノードが収まっているかどうかを確認せよ。インデックスが巨大化し、ディスクI/Oが発生し始めた瞬間、パフォーマンスは数桁落ちる。
運用上の注意：Write Amplification（書き込み増幅）
複合インデックスは読み込みを劇的に加速させるが、`wp_insert_post` や `wp_update_post` 時のオーバーヘッドを増加させる。特に `post_date` を含むインデックスは、投稿が更新されるたびにB+Treeの再構成を要求する可能性がある。
1. 書き込み頻度: 1秒間に数百件の更新があるシステムか？
2. 読み込み比率: `WP_Query` の実行頻度はどうか？
このバランスを計測し、`Read-Heavy` な環境であれば、迷わずこの複合インデックスを導入すべきだ。
—
結言：アーキテクトの視点
WordPressを単なるCMSとしてではなく、一つの「データランタイム」として捉えるならば、デフォルトのスキーマ設定はあくまで「汎用的な最小公倍数」に過ぎない。
`post_type` と `post_status` の複合インデックス設計は、データベース物理層の挙動を理解し、クエリプランナーと対話するための第一歩だ。我々シニアエンジニアの責務は、抽象化されたAPIの裏側にある、物理的なビットの並びを掌握し、ハードウェアの限界性能を引き出すことにある。
この最適化を適用した後の、ミリ秒単位で短縮されたクエリ実行時間こそが、エンジニアとしての魂の証明である。