【テクニカル・上級編】実務中級者向け：wp_postsテーブルの「post_type」と「post_status」に対する複合インデックスの有効性 – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

WP_Queryの深淵：`wp_posts` テーブルにおける複合インデックスの物理設計とクエリ最適化

WordPressのアーキテクチャにおいて、`WP_Query` は最も強力であると同時に、最も誤用されやすいブラックボックスの一つである。
特に、数百万件規模のレコードを持つ大規模なデータベースにおいて、デフォルトのインデックス戦略のままカスタム投稿タイプや複雑なメタデータ検索を実行することは、MySQL（あるいはMariaDB）のストレージエンジンに対して不必要なI/O負荷を強いる自殺行為に等しい。

本稿では、`wp_posts` テーブルの物理構造、オプティマイザの挙動、そして `post_type` と `post_status` に対する複合インデックス（Composite Index）の導入が、いかにしてクエリの実行計画（Execution Plan）を劇的に改善し、ランタイムのレイテンシを極限まで削り落とすかについて、低レイヤの視点から徹底的に解説する。

—

1. デフォルトインデックス構造の限界とコスト

まずは、標準的な WordPress インストールで生成される `wp_posts` テーブルのDDL（Data Definition Language）を確認する。

CREATE TABLE `wp_posts` (
`ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`post_author` bigint(20) unsigned NOT NULL DEFAULT 0,
`post_date` datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
`post_date_gmt` datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
`post_content` longtext NOT NULL,
`post_title` text NOT NULL,
`post_excerpt` text NOT NULL,
`post_status` varchar(20) NOT NULL DEFAULT ‘publish’,
`post_comment_status` varchar(20) NOT NULL DEFAULT ‘open’,
`post_ping_status` varchar(20) NOT NULL DEFAULT ‘open’,
`post_password` varchar(255) NOT NULL DEFAULT ”,
`post_name` varchar(255) NOT NULL DEFAULT ”,
`to_be_published` text NOT NULL,
`post_type` varchar(20) NOT NULL DEFAULT ‘post’,
— 省略 —
PRIMARY KEY (`ID`),
KEY `post_name` (`post_name`(191)),
KEY `type_status_date` (`post_type`,`post_status`,`post_date`,`ID`), — ※環境により異なる場合があるが標準は単体が多い
KEY `post_author` (`post_author`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

歴史的に、WordPressコアは各カラムに対して個別の単一カラムインデックス（Single-column Index）を張るアプローチをとってきた。しかし、実務で頻出する次のような `WP_Query` を発行したとき、何が起きるだろうか。

$query = new WP_Query([
‘post_type’ => ‘product’,
‘post_status’ => ‘publish’,
‘posts_per_page’ => 20,
‘orderby’ => ‘date’,
‘order’ => ‘DESC’,
]);

このPHPコードが生成するSQLは概ね以下のようになる。

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
WHERE wp_posts.post_type = ‘product’
AND wp_posts.post_status = ‘publish’
ORDER BY wp_posts.post_date DESC
LIMIT 0, 20;

ストレージエンジン（InnoDB）の内部挙動

ここで、もしデータベース内に `post`（通常の投稿）が1,000,000件、カスタム投稿タイプ `product` が50,000件存在していたとする。

MySQLのクエリパーサとオプティマイザが選択するインデックスは、統計情報（Cardinality）に基づいて決定される。もし `post_status` や `post_type` の単一インデックスしか存在しない場合、MySQLはどちらか一方のインデックスしか使用できない（あるいはテーブルスキャンを選択する）。
結果として、Index Merge（インデックスの結合）が発生するか、あるいは大量の行に対するUsing where / Using filesortが発生し、ランダムI/Oの嵐を引き起こす。メモリ上のバッファプール（InnoDB Buffer Pool）のヒット率は低下し、ディスクからのページ読み込み（Disk I/O）がボトルネックとなる。

—

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

この問題を根本から解決するのが、検索条件とソート条件のカーディナリティ（選択度）を考慮した複合インデックスの最適配置である。

B+Treeインデックスの構造上、複合インデックスは左端のプレフィックス（Leftmost Prefix）から順に評価される。そのため、カラムの並び順がパフォーマンスを決定づける。

最適なカラム順序の導出

1. 等価比較（Equality）を先頭に配置する：`post_type` および `post_status`
2. 範囲検索またはソート（Range / Sort）を後方に配置する：`post_date`

これを踏まえ、以下のDDLを実行してインデックスを追加する。

ALTER TABLE wp_posts ADD INDEX idx_ptype_pstatus_pdate (post_type, post_status, post_date);

このB+Treeインデックスが構築されると、InnoDBは次のような物理的最適化の恩恵を受ける。

1. 完全なインデックス駆動（Index Range Scan）:
`post_type` が ‘product’ であり、かつ `post_status` が ‘publish’ であるリーフノードの物理アドレスをB+Tree構造から一撃で特定し、その後の範囲を走査する。
2. ファイルソート（Using filesort）の回避:
インデックス自体がすでに `post_date` の順序でソートされているため、`ORDER BY post_date DESC` のための追加のソート処理（sort_buffer_sizeを消費するCPU処理）が完全にバイパスされる。

—

3. ベンチマークと実行計画（EXPLAIN）の検証

最適化の効果を定量的に証明するため、`EXPLAIN` を用いてクエリの実行計画を比較する。

最適化前の実行計画

EXPLAIN SELECT ID FROM wp_posts WHERE post_type = ‘product’ AND post_status = ‘publish’ ORDER BY post_date DESC LIMIT 20;

type: `ref` または `index`
key: `post_type`（単一インデックス）
Rows Examined: 数万〜数十万行
Extra: `Using where; Using filesort` （ディスクまたはメモリ上でのソートが発生）

複合インデックス導入後の実行計画

EXPLAIN SELECT ID FROM wp_posts WHERE post_type = ‘product’ AND post_status = ‘publish’ ORDER BY post_date DESC LIMIT 20;

type: `range`
key: `idx_ptype_pstatus_pdate`
Rows Examined: 20行（LIMIT句と連動して必要最小限のみスキャン）
Extra: `Using index condition` （インデックスプッシュダウン最適化の適用）

CPUサイクルとメモリ帯域の無駄な消費が消え去り、クエリの応答速度はミリ秒オーダーからマイクロ秒オーダーへと昇華する。

—

4. 実務における実装とメンテナンスの注意点

インデックスは万能の薬ではない。インデックスを追加するということは、書き込み（INSERT / UPDATE / DELETE）時のB+Tree維持コスト（書き込み増幅）を代償に支払うことを意味する。

特に投稿のステータス変更や自動下書き（auto-draft）が頻繁に行われる環境では、インデックスの断片化（Fragmentation）が進行する。定期的なテーブルのメンテナンスと、クエリキャッシュのレイヤを超えた最適化設計が不可欠である。

実務で使えるメンテナンス・監視スニペット

現在、どのようなクエリが `wp_posts` を圧迫しているかを特定するため、MySQLのパフォーマンススキーマ（Performance Schema）を叩くクエリを常備しておくと良い。

— 実行時間が長く、フルスキャンに近い挙動を示しているクエリを抽出
SELECT
digest_text,
count_star AS exec_count,
timer_wait/1000000000 AS total_latency_sec,
rows_examined
FROM performance_schema.events_statements_summary_by_digest
WHERE digest_text LIKE ‘%wp_posts%’
ORDER BY total_latency_sec DESC
LIMIT 5;

また、カスタム投稿タイプを動的に登録するプラグインやテーマを開発する際は、必要に応じてデータベースマイグレーションスクリプトを内包し、適切なインデックスの存在を担保するコードをライフサイクルにフックさせるべきである。

プラグイン有効化時にカスタムインデックスを安全に付与する例

/
function my_custom_plugin_activate() {
global $wpdb;
$table_name = $wpdb->posts;

// 既存のインデックス重複を防ぐためのチェック
$index_exists = $wpdb->get_results(
“SHOW INDEX FROM {$table_name} WHERE Key_name = ‘idx_ptype_pstatus_pdate'”
);

if (empty($index_exists)) {
$wpdb->query(
“ALTER TABLE {$table_name} ADD INDEX idx_ptype_pstatus_pdate (post_type, post_status, post_date)”
);
}
}
register_activation_hook( __FILE__, ‘my_custom_plugin_activate’ );

—

結びにかえて

WordPressは「ブログエンジン」という皮肉交じりの形容をされることがあるが、その実態はPHPとRDBMSの境界線上にある、極めて高度な動的アプリケーションプラットフォームである。

コアの仕様やプラグインの作法をなぞるだけの上級者で終わるか、データベースのストレージエンジン層、B+Treeの構造、そしてクエリプランナーの思考回路までを掌握し、スケールするシステムを構築するプロフェッショナルになるか。その境界線は、まさにこうした地道かつ本質的なインデックス設計の理解に他ならない。

コードを書く前に、SQLを見よ。SQLを見る前に、インデックスを見よ。
システムを真に支配する者よ、データベースの物理層に敬意を払え。