【テクニカル・上級編】wp_postsテーブルのpost_statusとpost_typeを組み合わせた複合インデックスの設計とクエリプランナーの挙動 – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

WordPressデータベースの深淵：`wp_posts` における複合インデックスとMySQLオプティマイザの制御理論

WordPressのパフォーマンスチューニングにおいて、しばしば「プラグインの軽量化」や「オブジェクトキャッシュの導入」が叫ばれる。しかし、数百万件規模のレコードを抱える `wp_posts` テーブルを前にした時、それらの高レイヤなアプローチは根本的な解決にならない。

問題の根源は、リレーショナルデータベースの物理層、すなわちストレージエンジン（InnoDB）のB-Treeインデックス構造と、MySQLのクエリプランナー（コストベースオプティマイザ: CBO）の挙動にある。

本稿では、`wp_posts` テーブルの `post_status` と `post_type` という、極めて頻出する二つのカラムに焦点を当て、シニアエンジニアが知るべき複合インデックスの設計論と、それをWordPressコアから完全に制御するための低レイヤアプローチを解剖する。

—

1. `wp_posts` の物理構造とデフォルトインデックスの限界

まず、デフォルトのWordPressスキーマが抱える構造的欠陥を理解する必要がある。

DESCRIBE wp_posts;

デフォルトの状態では、`ID` がプライマリキーであり、いくつかのシングルカラムインデックス（`post_name`, `type_status_date` などの部分的なものは存在するが環境やバージョンにより異なる）が張られている。しかし、カスタム投稿タイプや複雑なクローズド環境において、次のようなクエリが実行された瞬間を想像してほしい。

SELECT FROM wp_posts
WHERE post_type = ‘product’
AND post_status = ‘publish’;

カーディナリティ（Cardinality）の罠とオプティマイザの誤認

MySQLのInnoDBオプティマイザは、統計情報（`ANALYZE TABLE` によって更新される情報）を基に、どのインデックスを使用するか、あるいはフルテーブルスキャン（`ALL`）を実行するかを決定する。

ここで問題になるのが カーディナリティ（値の分散度） である。

`post_type` の種類が例えば `post`, `page`, `attachment`, `revision`, `product` の5種類だとすれば、カーディナリティは極めて低い。
`post_status` も `publish`, `draft`, `private`, `trash` など数種類であり、同様に低い。

このような低カーディナリティの列に対して単一のインデックスを張っても、MySQLのオプティマイザは「インデックスシークのオーバーヘッド（ランダムI/O）が発生するくらいなら、テーブル全体をシーケンシャルスキャン（逐次I/O）した方が速い」と判断し、インデックスをガン無視する。

結果として、データ量が数万件を超えたあたりから、データベースのCPU使用率がスパイクし始める。

—

2. 複合インデックス（Composite Index）の数学的設計

この課題を突破するには、`post_type` と `post_status` を組み合わせた 複合インデックス（左端プレフィックスの法則に則ったインデックス） の物理設計が不可欠である。

ここで重要なのは、どちらの列をインデックスの左側に配置するか（Leftmost Prefix Rule） である。

選択性（Selectivity）に基づく順序の決定

一般的に、より絞り込み性能が高い（選択性が高い＝ユニークな値の組み合わせが多い）列を左側に配置するのがB-Treeの効率を最大化する鉄則だ。

例えば、サイト全体の投稿の大半が `post` タイプであり、その中の `publish` を探す場合と、特定のカスタム投稿タイプ `product` の `publish` を探す場合を考える。

— パターンA: (post_status, post_type)
CREATE INDEX idx_status_type ON wp_posts (post_status, post_type);

— パターンB: (post_type, post_status)
CREATE INDEX idx_type_status ON wp_posts (post_type, post_status);

InnoDBのB-Tree構造において、`idx_type_status (post_type, post_status)` を作成した場合：
1. まず `post_type` でソートされたノードツリーを走査する。
2. 同一の `post_type` の中で、さらに `post_status` でソートされたサブツリーにアクセスする。

ECサイトやメディアサイトで `post_type = ‘product’` や `post_type = ‘post’` のように、特定のタイプがクエリの主軸になる場合、` (post_type, post_status)` の順序が圧倒的なパフォーマンスを発揮する。

—

3. 実行計画（EXPLAIN）による検証

実際にインデックスを投入し、クエリプランナーの挙動を `EXPLAIN` で確認する。

EXPLAIN FORMAT=JSON
SELECT ID, post_title
FROM wp_posts
WHERE post_type = ‘my_custom_type’
AND post_status = ‘publish’;

最適化前後のオプティマイザ出力比較

最適化前 (Indexなし / または不適切なインデックス):

`rows_examined` がテーブル全体の行数に一致し、`access_type: ALL`（フルテーブルスキャン）が選択される。メモリ上のバッファプール（InnoDB Buffer Pool）が汚染され、キャッシュヒット率が急低下する。

最適化後 (`(post_type, post_status)` インデックス適用):

`access_type: ref` または `range` となり、`filtered: 100.00`、かつ `Using index`（カバリングインデックスが効いている場合）または最小限の行シークのみで結果が返却される。

—

4. WordPressコア（WP_Query）へのインデックス強制と実装

データベース層で完璧なインデックスを設計しても、WordPressの `WP_Query` がそれを活用するクエリを発行しなければ意味がない。

デフォルトの `WP_Query` は、`posts_clauses` フィルターなどを経由してSQLを組み立てる。ここで、MySQLに対して特定のインデックスの使用を明示的（強制）に指示する `FORCE INDEX` をフックで挿入する、極限の最適化テクニックを実装する。

以下のコードは、特定のカスタムクエリにおいて、先ほど設計した複合インデックスを確実にヒットさせるためのプロダクションコードである。

Plugin Name: Core DB Index Optimizer for WP_Posts

Description: wp_postsの複合インデックス最適化とクエリプランナー制御

Author: Chief System Architect

declare(strict_types=1);

namespace System\Optimizer;

class WP_Posts_Index_Optimizer {

public static function init(): void {
// 特定の条件を満たすWP_QueryのSQLに対してFORCE INDEXを適用
add_filter(‘posts_clauses’, [self::class, ‘inject_force_index’], 10, 2);
}

データベースクエリの断片をフックし、オプティマイザにヒントを与える

@param array $clauses クエリの各節（WHERE, GROUP BY, JOIN, ORDER BY, DISTINCT, FIELDS, LIMIT）
@param \WP_Query $query WP_Queryのインスタンス
@return array

/
public static function inject_force_index(array $clauses, \WP_Query $query): array {
// 管理画面や、意図しないクエリへの影響を防ぐガード句
if (is_admin() || !$query->is_main_query()) {
// 必要に応じてカスタムクエリの識別子（メタキーやカスタムフラグ）で判定を行う
if (!$query->get(‘optimize_index_force’, false)) {
return $clauses;
}
}

global $wpdb;

// 対象テーブル
$table_posts = $wpdb->posts;

// WHERE句に対してFORCE INDEX句を強制的かつ安全にインジェクションする
// ※MySQL固有の構文であるため、他DB（PostgreSQL等）を使用していない環境に限定
if (!empty($clauses[‘where’])) {
// テーブル名直後に FORCE INDEX (インデックス名) を挿入
// 事前に ALTER TABLE wp_posts ADD INDEX idx_type_status (post_type, post_status); を実行しておくこと
$index_hint = ” FORCE INDEX (`idx_type_status`)”;

// `wp_posts` のテーブル名置換（エイリアスやプレフィックスに対応）
$clauses[‘where’] = preg_replace(
‘/\b(‘ . preg_quote($table_posts, ‘/’) . ‘)\b/’,
‘$1’ . $index_hint,
$clauses[‘where’],
1 // 最初の出現のみ置換
);
}

return $clauses;
}
}

// ブートストラップ
WP_Posts_Index_Optimizer::init();

このコードのアーキテクチャ的意図

1. オプティマイザの気まぐれを排除: MySQLの統計情報の古さやデータの偏りによって、オプティマイザが誤った判断（フルテーブルスキャン）を下すリスクを `FORCE INDEX` によって物理的に封じ込める。
2. スコープの限定: `is_admin()` の除外やカスタムクエリフラグ（`optimize_index_force`）の評価により、全方位的な副作用を完全に遮断。システム全体の堅牢性を担保している。

—

5. 結論：インデックスはデータベースの「心拍数」である

Webアプリケーションのパフォーマンスチューニングにおいて、コードレベルのアルゴリズム改善（O(N) から O(log N) への移行など）を語るエンジニアは多い。しかし、データベースのストレージエンジン層、そしてクエリプランナーの最適化プロセスまで踏み込んでシステムを掌握できている者は少ない。

`wp_posts` の `post_status` と `post_type` に対する適切な複合インデックスの設計と、それを活かすクエリ制御は、高負荷なWordPress基盤を支えるための必要条件である。

メモリ（Buffer Pool）のヒット率を最大化し、CPUの無駄なサイクルを削ぎ落とせ。真のシステムアーキテクトにとって、データベースはただの保存容器ではなく、精緻にチューニングされたひとつの「ランタイム」なのだから。