wp_postsの深淵：インデックスの物理構造とクエリプランナーの調教
大規模なWordPressサイトにおいて、`wp_posts`テーブルは単なるコンテンツの器ではない。数百万件規模のレコードが錯綜する時、この巨大なヒープテーブルはシステム全体のパフォーマンスを左右するクリティカルパスへと変貌する。
特に、カスタム投稿タイプ（CPT）を多用するアーキテクチャでは、MySQL（あるいはMariaDB）のクエリプランナーがいかにしてインデックスを選択し、ストレージエンジンがどのように行をフェッチしているかの物理的理解が不可欠だ。
本稿では、`wp_posts`における `post_type` カラムのインデックス挙動と、クエリプランナーの迷走を防ぎ実行計画を完全に掌握するための極限の最適化手法を解説する。
—
1. wp_postsの物理構造とインデックスの現実
WordPressのデフォルトスキーマにおいて、`wp_posts`テーブルのインデックス定義は以下のようになっている。
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_type` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ‘post’,
`post_status` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ‘publish’,
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;
ここで注目すべきは、複合インデックス `type_status_date` (`post_type`, `post_status`, `post_date`, `ID`) の存在だ。コアはこのインデックスによって、特定の投稿タイプとステータスを持つ投稿を時系列で効率的に取得しようとする。
しかし、この設計は「データ量とカーディナリティ（値の分散度）」のバランスが崩壊した瞬間、パフォーマンスのボトルネックへと転じる。
—
2. クエリプランナーの迷走とカーディナリティの罠
例えば、サイト内に `post`（通常の投稿）が 2,000,000件存在し、カスタム投稿タイプ `secret_spec` がたった 5件しか存在しないケースを想定せよ。
次のようなWP_Queryを発行したとする。
$query = new WP_Query([
‘post_type’ => ‘secret_spec’,
‘posts_per_page’ => 10,
‘post_status’ => ‘publish’,
]);
生成されるSQLは以下のようになる。
SELECT SQL_CALC_FOUND_ROWS wp_posts.
FROM wp_posts
WHERE wp_posts.post_type = ‘secret_spec’
AND wp_posts.post_status = ‘publish’
ORDER BY wp_posts.post_date DESC
LIMIT 0, 10;
オプティマイザの誤算
MySQLのオプティマイザ（Cost-based Optimizer: CBO）は、統計情報に基づいて最適な実行計画を選択する。しかし、`post_type` のような低カーディナリティ（値の種類が極めて少ない）カラムに対する統計情報の精度不足や、B+treeの走査コストの見積もりミスにより、CBOがあえてインデックスを使わず、フルテーブルスキャン（Table Scan）を選択することがある。
特に `SQL_CALC_FOUND_ROWS` が有効な場合、MySQLはすべての対象行をスキャンし、インデックスの恩恵を完全に殺してしまう。結果として、CPUバウンドな処理となり、スループットは劇的に低下する。
—
3. 複合インデックスの順序と「左端プレフィックス則」
B+treeインデックスは、左端プレフィックス則（Leftmost Prefix Rule）に従う。`type_status_date` (`post_type`, `post_status`, `post_date`, `ID`) の場合、クエリの条件句がこの順序、あるいはそれに準ずる形で評価されなければインデックスはフルに機能しない。
もし次のようなクエリを発行した場合、インデックスの効率は著しく低下する。
— post_status だけを指定した場合、post_type が最初のカラムにあるためインデックススキップスキャンやフルスキャンになる
SELECT FROM wp_posts WHERE post_status = ‘publish’;
さらに、`post_type` ごとのデータ量の偏りが極端な場合（Zipf分布に従うデータ構造）、単一の複合インデックスではクエリプランナーを常に正しい選択へ導くことが不可能になる。
—
4. 対策：マルチカラムインデックスの再設計と強制（Force Index）
極限のパフォーマンスを求めるシニアエンジニアは、デフォルトのコア構造に依存しない。特定のカスタム投稿タイプへのアクセスが頻発する場合、スキーマレベルでの介入を行う。
A. 専用の単一目的インデックスの追加
もし特定のカスタム投稿タイプ（例: `iot_sensor_data`）が数千万件規模に達し、頻繁に検索されるのであれば、コアのインデックスを触らずに（あるいはフックして）、特定のプレフィックスを持つインデックスを追加する。
— post_type と post_date に特化したカバリングインデックスの追加
ALTER TABLE wp_posts ADD INDEX idx_iot_type_date (`post_type`, `post_date` DESC, `ID`);
B. クエリプランナーへの介入（FORCE INDEX）
オプティマイザが誤った実行計画（フルスキャン）を選択し続ける場合、`posts_clauses` フィルターを用いて明示的にインデックスを強制する。
add_filter(‘posts_clauses’, function($clauses, \WP_Query $query) {
global $wpdb;
// 特定のカスタム投稿タイプかつ、高負荷なクエリでのみ介入
if ($query->get(‘post_type’) === ‘iot_sensor_data’) {
// テーブル名のエスケープとFORCE INDEXの挿入
$clauses[‘join’] .= ” FORCE INDEX (`idx_iot_type_date`)”;
}
return $clauses;
}, 10, 2);
【警告】 `FORCE INDEX` は諸刃の剣である。統計情報の更新（`ANALYZE TABLE`）やMySQLのバージョンアップによって逆効果になるリスクがあるため、必ず `EXPLAIN` を実行し、実行計画（Rows数、Typeが `range` や `ref` になっているか）を確認した上で適用すること。
—
5. データベース層における根本的なアプローチ
大規模WordPressシステムの設計において、`wp_posts` の肥大化は常に悪である。
1. トランザクションデータの分離:
ログやセンサーデータ、大量のメタを持つオブジェクトを `wp_posts` にインサートするのはアーキテクチャのアンチパターンである。専用のカスタムテーブル（例: `wp_custom_iot_logs`）を切り出し、WordPressのORM（$wpdb）で直接ハンドリングすべきだ。
2. SQL_CALC_FOUND_ROWSの排除:
WordPress 5.3以降、デフォルトで非推奨化の方向にあるが、大規模サイトでは明示的に `no_found_rows => true` を指定し、全件カウントのコスト（全行スキャン）を完全に排除せよ。
$query = new WP_Query([
‘post_type’ => ‘heavy_cpt’,
‘posts_per_page’ => 20,
‘no_found_rows’ => true, // FOUND_ROWS() をバイパスし、I/Oを激減させる
]);
結びにかえて
WordPressのパフォーマンスチューニングとは、PHPコードの最適化だけではない。MySQLというランタイムのストレージエンジン、B+treeの物理構造、そしてクエリプランナーの心理（アルゴリズム）を完全に把握し、予測可能なI/Oコストへ調教する作業そのものである。
インデックスの貼られた1バイトの差が、数百万リクエストの未来を救う。システムの深層を見据えた設計を続けよ。