WordPressを掌握せよ：`wp_term_relationships` のJOIN地獄を断つインデックス戦略
WordPressのデータベースにおいて、最も「無自覚に」クエリパフォーマンスを食いつぶす癌。それが `wp_term_relationships` テーブルだ。
タクソノミー（カテゴリやタグ）が増加し、`WP_Query` で複雑な絞り込みを行う際、MySQLが真っ先に悲鳴を上げるのがこのテーブルであることは、コアの内部構造を知るエンジニアであれば自明の理だ。なぜなら、デフォルトのインデックス設計は、大規模データセットにおける「検索の柔軟性」を担保するために、物理的なパフォーマンスを犠牲にしているからだ。
今日は、このボトルネックを物理層から叩き直す、プロフェッショナルな最適化戦略を伝授する。
—
1. なぜデフォルトのインデックスでは不十分なのか
`wp_term_relationships` のデフォルトスキーマを確認してほしい。
PRIMARY KEY (`object_id`, `term_taxonomy_id`),
KEY `term_taxonomy_id` (`term_taxonomy_id`)
WordPressは `object_id` と `term_taxonomy_id` の複合主キーを持っている。これ自体は整合性を保つ上では正しい。しかし、現実のWebアプリケーションでは、「特定のタクソノミーに属する投稿を、IDでソートして取得する」といったクエリが頻発する。
ここで発生するのが 「Filesort」と「Temporary Table」の発生 だ。MySQLは、タクソノミーによる絞り込みの後、`wp_posts` テーブルとのJOINやソートを行うために、インデックスが最適化されていないとフルスキャンに近い挙動を見せる。
2. 物理インデックスの「再設計」：複合インデックスの定石
もし君が管理するサイトのタクソノミー検索が重いなら、以下の複合インデックスを追加検討すべきだ。ただし、「書き込み（INSERT/UPDATE）コストとのトレードオフ」を理解している前提で進める。
推奨インデックス戦略
`term_taxonomy_id` を先頭に置いた複合インデックスを貼ることで、特定のタクソノミー配下の `object_id` を高速に解決できる。
— 既存のインデックスに加えて、検索クエリの実行計画を最適化する
ALTER TABLE wp_term_relationships
ADD INDEX idx_taxonomy_object (term_taxonomy_id, object_id);
なぜこれが効くのか？
- `term_taxonomy_id` での絞り込みが、B-Treeの走査だけで完結する。
- `object_id` が含まれていることで、`wp_posts` テーブルとのJOINに必要なキーが「カバリングインデックス」として機能し、データページへのランダムアクセスを劇的に減らすことができる。
—
3. 実践：WordPressでインデックスの最適化を制御する
手動でSQLを叩くのは一過性の解決策に過ぎない。プロダクション環境では、デプロイ時にDB構造を整合させる設計が必要だ。以下は、プラグインやテーマのインストール・アップデート時に実行すべき、堅牢なインデックス適用コードである。
/
- データベースの物理構造を最適化するためのインフラ・クラス
/
class DB_Performance_Optimizer {
public static function add_custom_term_index() {
global $wpdb;
$table_name = $wpdb->term_relationships;
$index_name = ‘idx_taxonomy_object’;
// 既にインデックスが存在するか確認（不要なエラーを防ぐため）
$indexes = $wpdb->get_results(“SHOW INDEX FROM {$table_name} WHERE Key_name = ‘{$index_name}'”);
if (empty($indexes)) {
// 実行コストを考慮し、非同期またはメンテナンスモードでの実行を推奨
$wpdb->query(“ALTER TABLE {$table_name} ADD INDEX {$index_name} (term_taxonomy_id, object_id)”);
}
}
}
// 適切なタイミング（activation hookなど）で実行
register_activation_hook(__FILE__, [‘DB_Performance_Optimizer’, ‘add_custom_term_index’]);
—
4. 現場のテックリードからの警告
この最適化を行う上で、絶対に忘れてはならない注意点がある。
1. インデックスの重複排除: `wp_term_relationships` は全ての投稿タイプで共有される。特定のカスタム投稿タイプのためだけに過剰なインデックスを貼ると、全投稿タイプの保存処理が遅延する。
2. 実行計画（EXPLAIN）の確認: `EXPLAIN SELECT …` を必ず実行せよ。`key` カラムが意図したインデックスを指しているか、`rows` が最小化されているかを確認しないエンジニアは、単なる「勘」でコードを書いているに等しい。
3. キャッシュ層との併用: データベースへの直接アクセスは、どれほど最適化しても限界がある。`wp_cache_` (Object Cache) を使い、複雑なタクソノミー結合クエリの結果は必ずメモリに退避させろ。
結論：コードは「物理層」まで到達して完成する
WordPressを「ただのCMS」として扱うか、「巨大なデータプラットフォーム」として扱うかは、君の設計思想次第だ。`wp_term_relationships` のような基幹テーブルのインデックスを制御することは、システムの血液循環を整えることに等しい。
「なんとなく遅い」を解決するのは、直感ではなく、MySQLのインデックス構造とWordPressのクエリ生成アルゴリズムへの深い洞察だ。さあ、今すぐ `EXPLAIN` を叩き、君のシステムの真の姿を可視化してほしい。