WordPressを極限まで速くする：`wp_posts.post_type` インデックスの物理的真実とクエリ最適化
コードレビューをしていると、次のようなカスタム投稿タイプ（CPT）のデータ取得クエリをいまだに見かけることがある。
// 最悪のアンチパターン例
$posts = get_posts(array(
‘post_type’ => ‘my_custom_post’,
‘meta_query’ => array(
array(
‘key’ => ‘is_featured’,
‘value’ => ‘1’,
),
),
));
一見、何の問題もない標準的なコードに見えるだろうか？
もしあなたのサイトの `wp_posts` テーブルに数万〜数百万件のレコードが存在し、`post_type` カラムに適切なインデックス貼られていない（あるいはデフォルトのままである）場合、このクエリはデータベースサーバーのCPUを焼き尽くす時限爆弾に化ける。
今回は、WordPressのデータベーススキーマの根幹である `wp_posts` テーブルの物理構造、特に `post_type` カラムに対するインデックスの重要性 と、大規模サイトで破綻しないためのクエリ設計戦略を、テクニカルリードの視点からロジカルかつシャープに解説する。
—
1. WordPressコアが抱えるデータベース構造の原罪
まず、デフォルトのWordPressスキーマ（MySQL / MariaDB）を確認しよう。
`wp_posts` テーブルのDDL（構造定義）を思い浮かべてほしい。
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_status` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ‘publish’,
`post_type` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT ‘post’,
`post_name` varchar(200) COLLATE utf8mb4_unicode_ci NOT NULL,
— 中略 —
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=InnoDB;
ここで重要な事実がある。初期状態のWordPressコアにおいて、`post_type` 単体に対する独立したインデックスは存在しない。
通常、WordPressは複合インデックス（例: `type_status_date` や、環境によっては含まれないケースもある）に依存している。しかし、クエリの条件句（WHERE句）がこの複合インデックスの左端プレフィックス規則に一致しない場合、あるいは `meta_query` や `tax_query` が絡む複雑なJOINが発生した場合、オプティマイザは悲惨な選択を下す。
フルテーブルスキャン（全件走査）の悪夢
`post_type` にインデックスがない状態で、以下のようなクエリが発行されたとする。
SELECT FROM wp_posts WHERE post_type = ‘my_custom_post’ AND post_status = ‘publish’;
もし複合インデックスの順序や構成がオプティマイザに無視された場合、MySQLは テーブル全体の行（数百万行）を上から順にすべてスキャン（Full Table Scan） し、条件に合致する行を探し始める。ディスクI/Oは跳ね上がり、QPS（Query Per Second）は急低下、データベースのコネクションプールは枯渇する。これが、カスタム投稿タイプを多用するサイトで突然パフォーマンスが崩壊するメカニズムだ。
—
2. クエリ実行計画（EXPLAIN）から読み解く最適化の劇的変化
インデックスの有無がどれほど実行計画（Execution Plan）を変えるのか、実務の現場感覚で比較してみよう。
インデックス未整備時の `EXPLAIN`
EXPLAIN SELECT ID FROM wp_posts WHERE post_type = ‘my_custom_post’;
- Type: `ALL` （フルテーブルスキャン）
- Rows: `1,250,000` （全行を調査）
- Extra: `Using where`
`post_type` にインデックスを追加した後の `EXPLAIN`
ALTER TABLE wp_posts ADD KEY idx_post_type (post_type);
EXPLAIN SELECT ID FROM wp_posts WHERE post_type = ‘my_custom_post’;
- Type: `ref` （インデックス参照）
- Rows: `450` （該当する候補行のみを特定）
- Extra: `Using index condition`
スキャンする行数が 1,250,000 から 450 に激減する。これが、データベース設計においてインデックスが「魔法」と呼ばれる理由だ。
—
3. 実務で使える：インデックス強制とカスタムクエリ設計のベストプラクティス
では、コードレビューで「このクエリは遅い」と言われないために、シニアエンジニアとしてどのような実装を行えばよいか。
以下のプロダクションコードは、カスタム投稿タイプの取得において 不要なJOINやメタデータ検索を排除し、インデックスを確実にヒットさせる ための堅牢な設計パターンである。
/
declare(strict_types=1);
namespace Enterprise\Core\Database;
class Optimized_Post_Fetcher {
/
- パフォーマンスを最適化したカスタム投稿の取得
- @param string $post_type 投稿タイプ名
- @param int $limit 取得件数
- @return array WP_Postオブジェクトの配列
/
public static function get_posts_by_type( string $post_type, int $limit = 10 ): array {
global $wpdb;
// 1. キャッシュ層の確認（データベースにヒットさせる前にTransientで弾く）
$cache_key = ‘opt_posts_’ . md5( $post_type . ‘_’ . $limit );
$cached = get_transient( $cache_key );
if ( false !== $cached ) {
return $cached;
}
// 2. プリペアドステートメントによる安全かつ高速なクエリの構築
// post_typeインデックスが確実に機能するよう、余計なJOINを避けてIDのみを高速に抽出する。
$query = $wpdb->prepare(
“SELECT ID
FROM {$wpdb->posts}
WHERE post_type = %s
AND post_status = ‘publish’
ORDER BY post_date DESC
LIMIT %d”,
$post_type,
$limit
);
// クエリキャッシュやインデックス効力を評価するため、必要に応じてデバッグログへEXPLAINを流すことも有効
// $this->log_explain( $query );
$post_ids = $wpdb->get_col( $query );
if ( empty( $post_ids ) ) {
set_transient( $cache_key, array(), MINUTE_IN_SECONDS 10 );
return array();
}
// 3. WP_Postオブジェクトのキャッシュ効率化（update_post_cache）
// ガタガタの個別クエリを発行するのではなく、prime_post_cachesを一発挟む
_prime_post_caches( $post_ids, true, true );
$posts = array();
foreach ( $post_ids as $id ) {
$post = get_post( $id );
if ( $post ) {
$posts[] = $post;
}
}
// 4. トランジェントに結果を保存（有効期限10分）
set_transient( $cache_key, $posts, MINUTE_IN_SECONDS 10 );
return $posts;
}
}
このコードの優れた設計ポイント
1. 二段階フェッチの採用 (`ID` のみを先に取得)
`SELECT ` を避け、まずインデックスが効く `post_type` と `post_status` で絞り込んで `ID` のみを取得している。これによりメモリ消費量とデータベースの負荷を最小限に抑える。
2. `_prime_post_caches()` によるN+1問題の完全撲滅
取得したID群に対して WordPress コアのオブジェクトキャッシュを一括プライミング（暖機）することで、後続の `get_post()` 呼び出しにおけるメタデータの追加クエリを完全に防いでいる。
3. トランジェントキャッシュの併用
データベースへのヒット自体を削減する。インデックスチューニングは重要だが、「クエリを投げないこと」が最強のパフォーマンス最適化であることに変わりはない。
—
4. テクニカルリードからの最終提言
カスタム投稿タイプを無秩序に増やし、それを `WP_Query` のデフォルト任せで重い `meta_query` や `tax_query` と組み合わせる設計は、技術的負債の温床となる。
もしあなたのプロジェクトでデータベースのCPU使用率が高騰しているなら、今すぐ以下の施策を実施してほしい。
1. スロークエリログを有効化し、`wp_posts` に対するフルテーブルスキャンを特定する。
2. 必要に応じて、マイグレーションスクリプトやDB管理ツールで `post_type` 単体、あるいはよく使われる複合インデックスが適切に張られているか確認する。
3. データ構造とクエリのライフサイクルをコードレベルで見直し、無駄なJOINやスキャンが発生していないか厳しくコードレビューを行う。
インデックスの貼られていないデータ構造は、目隠しをして地雷原を歩くようなものだ。
システムの内部構造を掌握し、美しく堅牢なアーキテクチャを構築してこそ、真のプロフェッショナルといえる。