WordPressを極限まで加速させるデータベースエンジニアリング：`wp_term_relationships` の複合インデックス最適化
コードレビューをしていると、数万件以上のカスタム投稿を持つ大規模なWordPressサイトで、カスタムタクソノミーや複数のタームを組み合わせた検索クエリがボトルネックになっているケースに度々遭遇する。
「なぜこのクエリは重いのか？」
「なぜMySQLのCPU使用率が跳ね上がるのか？」
その原因の多くは、WordPressのコアがデフォルトで提供するスキーマの限界、そしてそれを理解せずに発行される非効率な `JOIN` と `WHERE` 句にある。特に、複数タームの絞り込み検索（AND検索）において、`wp_term_relationships` テーブルのインデックス戦略を誤ると、データベースはフルテーブルスキャン（またはそれに近い状態）に陥る。
今回は、WordPressのデータベース内部構造、とりわけ `wp_term_relationships` の物理構造にメスを入れ、複合インデックスの順序設計によってクエリを劇的に高速化する実践的なアプローチを解説する。
—
1. なぜデフォルトの `wp_term_relationships` はスケールしないのか？
まず、WordPressのデフォルトスキーマを確認しよう。`wp_term_relationships` は極めてシンプルに設計されている。
- `object_id` (bigint)
- `term_taxonomy_id` (bigint)
- `term_order` (int)
そして、デフォルトのインデックス構成は以下のようになっている。
- プライマリキー：(`object_id`, `term_taxonomy_id`) または (`term_taxonomy_id`, `object_id`) ※バージョンや環境により微差はあるが、基本はこの複合または個別。
ここで、「特定のカテゴリー（`term_taxonomy_id`）に属し、かつ特定のタグ（別の `term_taxonomy_id`）を持つ投稿を効率よく取得したい」という、ECサイトのファセット検索やメディアサイトの高度な絞り込み検索を考えてみる。
次のようなSQLが発行される。
SELECT p.
FROM wp_posts p
INNER JOIN wp_term_relationships tr1 ON (p.ID = tr1.object_id)
INNER JOIN wp_term_relationships tr2 ON (p.ID = tr2.object_id)
WHERE tr1.term_taxonomy_id = 123
AND tr2.term_taxonomy_id = 456
AND p.post_type = ‘product’
AND p.post_status = ‘publish’;
このクエリ、データ量が100万件を超えてくると途端に応答速度が数百ミリ秒〜数秒に悪化する。
なぜか？ MySQLのオプティマイザがどのインデックスをどう使うべきか迷い、あるいは不適切なインデックススキャンを選択してしまうからだ。「どのカラムを左側に置くか（左端prefixの原則）」を無視したクエリとインデックスのミスマッチがここで起きている。
—
2. 複合インデックスの順序設計：エンジニアリングの極意
B-Treeインデックスの構造上、複合インデックスの列順序はパフォーマンスを決定づける絶対的な要素である。
`wp_term_relationships` において、我々が最適化すべきクエリのパターンは主に2つある。
1. 「あるタームに属する投稿ID一覧を取得する」 (`term_taxonomy_id` から `object_id` を引く)
2. 「特定の投稿がどのタームに属しているか取得する」 (`object_id` から `term_taxonomy_id` を引く)
デフォルトのプライマリキーやインデックスは万能を目指すがゆえに、複雑なマルチターム絞り込み（AND検索）の `JOIN` において真価を発揮しきれない。
ここで、プロダクション環境で投入すべきカスタム複合インデックスの設計指針を提示する。
最適化されたインデックスの定義案
— 1. term_taxonomy_id を先頭にしたインデックス（ターム基準の絞り込み用）
ALTER TABLE wp_term_relationships
ADD INDEX idx_term_object (term_taxonomy_id, object_id);
— 2. object_id を先頭にしたインデックス（投稿基準の結合用 ※通常PKでカバーされるが明示的に定義する場合）
— ALTER TABLE wp_term_relationships
— ADD INDEX idx_object_term (object_id, term_taxonomy_id);
「たったこれだけか？」と思うかもしれない。しかし、この `idx_term_object (term_taxonomy_id, object_id)` が存在することで、MySQLは `WHERE term_taxonomy_id = 123` に該当するインデックス範囲を瞬時に特定し、そこに含まれる `object_id` のリストをメモリ上で効率的に処理（ICP: Index Condition Pushdownなど）できるようになる。
—
3. 実務で即効性を発揮するプロダクションコード
単にデータベースを変更するだけでは不十分だ。WordPressの抽象化層（`WP_Query`）は非常にリッチだが、時として我々が意図しない冗長なSQLを生成する。
以下のコードは、カスタムインデックスを最大限に活かしつつ、多重タクソノミーのAND検索を極限まで高速化する `WP_Query` のラッパー関数だ。コードレビューでそのまま承認されるレベルの堅牢性と保守性を担保している。
/
namespace Enterprise\Optimization;
/
- 複数のタームIDによる高速AND検索を実行する
- @param array $term_taxonomy_ids 絞り込む term_taxonomy_id の配列
- @param string $post_type 投稿タイプ
- @return int[] マッチした投稿IDの配列
/
function get_objects_by_taxonomies_and( array $term_taxonomy_ids, string $post_type = ‘post’ ): array {
global $wpdb;
// 入力値のサニタイズとバリデーション
$term_taxonomy_ids = array_map( ‘absint’, $term_taxonomy_ids );
if ( empty( $term_taxonomy_ids ) ) {
return [];
}
$post_type = sanitize_key( $post_type );
$count = count( $term_taxonomy_ids );
// 動的にJOIN句を構築するが、インデックス ‘idx_term_object’ が完全に機能する構造にする
// 各タームごとにテーブルをJOINし、AND条件で絞り込む
$join_clauses = [];
for ( $i = 0; $i < $count; $i++ ) {
$alias = 'tr_' . $i;
$id = $term_taxonomy_ids[$i];
// プリペアドステートメント用のプレースホルダーを安全に埋め込む
$join_clauses[] = $wpdb->prepare(
“INNER JOIN {$wpdb->term_relationships} AS {$alias} ON p.ID = {$alias}.object_id AND {$alias}.term_taxonomy_id = %d”,
$id
);
}
$joins = implode( “\n”, $join_clauses );
// クエリの構築
// SQL_CALC_FOUND_ROWS は最新のMySQL/MariaDBでは非推奨かつ低速なため使用せず、純粋なパフォーマンスを追求する
$sql = ”
SELECT p.ID
FROM {$wpdb->posts} AS p
{$joins}
WHERE p.post_type = %s
AND p.post_status = ‘publish’
GROUP BY p.ID
“;
// プリペアドステートメントの安全性を確保するため、post_typeをバインド
$prepared_sql = $wpdb->prepare( $sql, $post_type );
// キャッシュ戦略: オブジェクトキャッシュ（Memcached / Redis）を活用し、DBへのヒット自体を削減する
$cache_key = ‘fast_tax_and_’ . md5( implode( ‘_’, $term_taxonomy_ids ) . ‘_’ . $post_type );
$cache_group = ‘enterprise_queries’;
$post_ids = wp_cache_get( $cache_key, $cache_group );
if ( false === $post_ids ) {
// DBから直接IDの配列を取得（メモリ効率を考慮しオブジェクト全体ではなくIDのみ取得）
$post_ids = $wpdb->get_col( $prepared_sql );
// 永続キャッシュに3600秒保存（タームや投稿が更新された際のパージ処理は別途トランザクションやフックで担保すること）
wp_cache_set( $cache_key, $post_ids, $cache_group, HOUR_IN_SECONDS );
}
return array_map( ‘absint’, $post_ids );
}
—
4. パフォーマンス上の注意点とアーキテクチャの罠
このアプローチを導入するにあたり、シニアエンジニアとして知っておくべき「罠」がいくつか存在する。
1. カバリングインデックス（Covering Index）の可能性
もしクエリで取得するのが `p.ID` だけであれば、`wp_posts` 側のインデックス（`post_type`, `post_status`, `ID`）と `wp_term_relationships` の複合インデックスを組み合わせることで、テーブル本体（Rows）へのアクセスを完全にゼロにする（Index-Only Scan）ことが理論上可能になる。MySQLのバージョンやオプティマイザの挙動によってEXPLAINの結果は変わるため、必ず本番同等のデータ量で `EXPLAIN` コマンドを実行し、`Using index` がフックされているか確認してほしい。
2. 書き込み（INSERT / UPDATE）へのフリクション
インデックスを追加すればするほど、データの書き込み（投稿の保存、タームの紐付け変更）時のコスト（B-Treeの再バランス）が増加する。
アクセス頻度が「読み込み 99% : 書き込み 1%」のような一般的なメディア・ECサイトであれば上記の最適化の恩恵が圧倒的に勝るが、リアルタイムで秒単位の書き込みが発生するシステムでは、インデックスの数とパフォーマンスのトレードオフを厳密にベンチマーク測定する必要がある。
3. オブジェクトキャッシュとの組み合わせが最強の解
どれほどデータベースのインデックスを最適化し、クエリを高速化（例: 50ms → 2ms）したとしても、アクセスが集中するトラフィック下ではデータベースサーバのネットワーク帯域がボトルネックになる。
前述のコード例のように、「最適化されたSQL ＋ 堅牢なオブジェクトキャッシュ（Redis等）」の二段構えこそが、WordPressを真のエンタープライズグレードへ引き上げる唯一のパスポートである。
—
結びにかえて
WordPressは「ブログのためのCMS」から「エンタープライズ向けのWebアプリケーションプラットフォーム」へと進化を遂げた。しかし、その根底にあるデータベース構造はレガシーな部分を残している。
フレームワークが隠蔽してくれる抽象化の裏側で何が起きているのかを理解し、SQLの実行計画（EXPLAIN）を読み解き、適切なインデックスを設計する。この泥臭くも美しいエンジニアリングの積み重ねこそが、数百万PVを誇る巨大サイトを平穏に稼働させ続ける唯一の秘訣である。
あなたのサイトの `wp_term_relationships` は、今、悲鳴を上げていないか？
今すぐ `EXPLAIN` を叩き、データベースの声を聴け。