なぜ、あなたのWP_Queryは数百万件のレコードの前に沈黙するのか
コードレビューをしていて、最も背筋が凍る瞬間のひとつがこれだ。
// 最悪のアンチパターン
$args = array(
‘post_type’ => ‘product’,
‘posts_per_page’ => 20,
‘tax_query’ => array(
‘relation’ => ‘AND’,
array(
‘taxonomy’ => ‘product_cat’,
‘field’ => ‘slug’,
‘terms’ => ‘electronics’,
),
array(
‘taxonomy’ => ‘product_tag’,
‘field’ => ‘slug’,
‘terms’ => array( ‘sale’, ‘featured’ ),
‘operator’ => ‘IN’,
),
),
);
$query = new WP_Query( $args );
一見して何の問題もない美しいコードに見えるだろうか？ もしそう感じたなら、あなたは大規模WordPressサイトの運用において、まだ地獄の底を見たことがない幸せなエンジニアだと言わざるを得ない。
投稿数が数十万、ターム数が数千、そしてそれらが複雑に絡み合うECサイトやメディアサイトにおいて、上記のクエリは確実にデータベースを膝折れさせる。犯人は、WordPressのコアが隠蔽している怪物、`wp_term_relationships` テーブルだ。
今回は、この結合テーブルの肥大化が引き起こすパフォーマンスの崩壊メカニズムを解剖し、インデックスチューニングと設計思想の観点から、このボトルネックを完全にねじ伏せるプロフェッショナルな手法を伝授する。
—
1. 内部解剖：なぜ `wp_term_relationships` はスロークエリの温床になるのか
WordPressのデータベース構造において、投稿（`wp_posts`）とタクソノミー（`wp_term_taxonomy`）の多対多（N:M）の関係を管理しているのが `wp_term_relationships` テーブルだ。
このテーブルの構造は極めてシンプルである。
- `object_id` (bigint)
- `term_taxonomy_id` (bigint)
- `term_order` (int)
主キーは `(object_id, term_taxonomy_id)` の複合プライマリキー。しかし、複数のタクソノミーを `tax_query` で `AND` 結合して検索したとき、MySQL（InnoDB）のオプティマイザが何をやっているか、実行計画（EXPLAIN）を見たことがあるだろうか？
複数の `JOIN` による地獄
先ほどのような複数条件の `tax_query` を発行すると、WordPressは内部で以下のようなSQLを生成する（簡略化）。
SELECT SQL_CALC_FOUND_ROWS wp_posts.
FROM wp_posts
INNER JOIN wp_term_relationships AS tr1 ON (wp_posts.ID = tr1.object_id)
INNER JOIN wp_term_taxonomy AS tt1 ON (tr1.term_taxonomy_id = tt1.term_taxonomy_id)
INNER JOIN wp_term_relationships AS tr2 ON (wp_posts.ID = tr2.object_id)
INNER JOIN wp_term_taxonomy AS tt2 ON (tr2.term_taxonomy_id = tt2.term_taxonomy_id)
WHERE tt1.taxonomy = ‘product_cat’ AND tt1.term_id = 123
AND tt2.taxonomy = ‘product_tag’ AND tt2.term_id IN (456, 789)
AND wp_posts.post_type = ‘product’
AND wp_posts.post_status = ‘publish’
GROUP BY wp_posts.ID;
投稿数が100万件、各投稿に平均5個のタグやカテゴリが紐づいているとしよう。`wp_term_relationships` のレコード数は 500万行 に達する。
このテーブルに対して、同じテーブルを何回も自己結合（Self-Join）させ、さらに `GROUP BY` と `SQL_CALC_FOUND_ROWS`（これがまた悪名高いパフォーマンス泥棒だ）を走らせる。
結果、MySQLのバッファプールは溢れ返り、ディスクからのランダムI/Oが発生、スロークエリログの常連が誕生するというわけだ。
—
2. インデックスチューニングの限界とデータベースレベルの対策
「じゃあ、インデックスを追加すればいいじゃないか」と思ったそこのあなた。半分正解で、半分は実務を知らない素人だ。
デフォルトの `wp_term_relationships` には、`term_taxonomy_id` に対するインデックスが存在しない（主キーが `object_id` 先頭の複合キーであるため）。そのため、特定のタームに属する投稿を引く逆引きクエリ（例：あるタグがついた全投稿を取得）では、フルスキャンが発生しやすい。
対策A: 不足しているインデックスの追加
次のようなDDLを実行し、逆引き用のインデックスを明示的に付与することは基本中の基本だ。
— term_taxonomy_id を先頭にしたインデックスを追加
ALTER TABLE wp_term_relationships
ADD INDEX idx_term_taxonomy_id (term_taxonomy_id);
しかし、テーブル自体が数千万行規模に肥大化した場合、B-Treeインデックスのサイズ自体がメモリを圧迫し、インデックスが機能しなくなる「インデックス肥大化の罠」に陥る。
ここで発想を変えなければならない。「何でもかんでもタクソノミー（階層・タグ構造）で表現しようとする設計の怠慢」を断ち切ることだ。
—
3. 堅牢な設計パターン：メタデータへのオフロードとカスタムテーブル
もし、あなたのプロジェクトが以下のような要件を含んでいるなら、タクソノミーの使用を見直すべきだ。
1. ターム数が数万件を超える（例：ユーザーID、商品型番、外部連携ID）
2. 階層構造が不要（親子関係がない）
3. 書き込み頻度が非常に高い
アプローチ1: `wp_postmeta` へのスライド
「カテゴリほど厳密な階層やアーカイブページが必要ない属性（例：ブランド、メーカー、色、在庫フラグ）」であれば、タクソノミーではなくメタデータとして保持するべきだ。
// 登録時：タクソノミーではなくメタとして保存
update_post_meta( $post_id, ‘_product_brand’, ‘apple’ );
`wp_postmeta` も肥大化しやすいが、検索クエリにおいて `meta_query` は単一のテーブル結合（またはサブクエリ）で完結するため、`wp_term_relationships` を複数JOINするクエリよりも圧倒的にオプティマイザが最適化しやすい。さらに、`meta_key` と `meta_value` に対する適切な複合インデックスを貼ることで、パフォーマンスを劇的に改善できる。
アプローチ2: 完全なカスタムテーブルの切り出し（プロダクション・レベル）
数百万件規模の高速な絞り込み検索（ファセット検索など）が必要な場合、WordPressのデフォルト構造に頼るのは諦めよう。完全に独立したカスタムテーブルを作成し、非同期（Action Scheduler等）で同期するアーキテクチャを採用するのがプロの選択だ。
以下に、実務で使える堅牢なカスタムテーブル設計とクエリ実行のサンプルコードを示す。
/
class HP_Product_Index_Manager {
private static $table_name = ‘wp_hp_product_index’;
/
- プラグイン有効化時に超高速検索用のカスタムテーブルを生成
/
public static function create_custom_table() {
global $wpdb;
$charset_collate = $wpdb->get_charset_collate();
$table = $wpdb->prefix . ‘hp_product_index’;
$sql = “CREATE TABLE $table (
product_id BIGINT(20) UNSIGNED NOT NULL,
category_id BIGINT(20) UNSIGNED NOT NULL,
brand_id BIGINT(20) UNSIGNED NOT NULL,
price DECIMAL(10,2) UNSIGNED NOT NULL,
stock_status TINYINT(1) NOT NULL DEFAULT 1,
PRIMARY KEY (product_id),
INDEX idx_cat_price (category_id, price),
INDEX idx_brand (brand_id)
) $charset_collate;”;
require_once( ABSPATH . ‘wp-admin/includes/upgrade.php’ );
dbDelta( $sql );
}
/
- WP_Query を使わず、カスタムテーブルから直接高速にIDsを取得する
- @param array $args 検索条件
- @return array 投稿IDの配列
/
public static function fast_search( $args = array() ) {
global $wpdb;
$table = $wpdb->prefix . ‘hp_product_index’;
$category_id = isset( $args[‘category_id’] ) ? absint( $args[‘category_id’] ) : 0;
$brand_id = isset( $args[‘brand_id’] ) ? absint( $args[‘brand_id’] ) : 0;
$max_price = isset( $args[‘max_price’] ) ? floatval( $args[‘max_price’] ) : 0;
$limit = isset( $args[‘limit’] ) ? absint( $args[‘limit’] ) : 20;
// 構築するクエリは極めてシンプルかつ、インデックスを完全にヒットさせる設計
$where = array( ‘stock_status = 1’ );
$sql_args = array();
if ( $category_id ) {
$where[] = ‘category_id = %d’;
$sql_args[] = $category_id;
}
if ( $brand_id ) {
$where[] = ‘brand_id = %d’;
$sql_args[] = $brand_id;
}
if ( $max_price > 0 ) {
$where[] = ‘price <= %f';
$sql_args[] = $max_price;
}
$where_clause = implode( ' AND ', $where );
$query = $wpdb->prepare(
“SELECT product_id FROM {$table} WHERE {$where_clause} ORDER BY price ASC LIMIT %d”,
array_merge( $sql_args, array( $limit ) )
);
// キャッシュ戦略：Object Cache (Redis/Memcached) へ直結させる
$cache_key = ‘hp_search_’ . md5( $query );
$results = wp_cache_get( $cache_key, ‘hp_search’ );
if ( false === $results ) {
$results = $wpdb->get_col( $query );
wp_cache_set( $cache_key, $results, ‘hp_search’, HOUR_IN_SECONDS );
}
return $results;
}
}
// 活性化フック
register_activation_hook( __FILE__, array( ‘HP_Product_Index_Manager’, ‘create_custom_table’ ) );
このコードの何が優れているのか？
1. ゼロ・ジョイン（Zero JOIN）: 複数のテーブルを結合せず、単一のカスタムテーブルからプレフィックス付きインデックス（`idx_cat_price`）を完璧にヒットさせて `product_id` のみを爆速で引き抜く。
2. Object Cacheの徹底活用: データベースへのヒット自体をキャッシュキーで完全にバイパスし、DB負荷を最小化する。
3. WordPressの呪縛からの解放: `WP_Query` の重厚長大なオーバーヘッド（メタデータの自動ロード、タームキャッシュの構築など）を完全に排除している。
—
4. テクニカルリードからの最終提言
WordPressは優れたCMSだが、それは「デフォルトの設計のまま何百万件ものリレーションを処理できる魔法の箱」ではない。
`wp_term_relationships` の肥大化に直面したとき、シニアエンジニアが取るべきアプローチは以下の3点だ。
1. プロファイリングを怠るな: `Query Monitor` や `EXPLAIN` を用い、どのクエリがテーブルスキャンを引き起こしているかを常時監視せよ。
2. タクソノミーを乱用するな: 「何でもかんでもタグやカテゴリにする」という前端層の安易な設計をコードレビューで弾き返せ。
3. 必要であればコアをバイパスしろ: パフォーマンスがビジネス要件を満たさないのであれば、WordPressの作法に囚われず、専用のインデックステーブルとキャッシュ層を構築する勇気を持て。
システムの本質を見極め、データベースの挙動を支配すること。それこそが、プロフェッショナルなWordPressエンジニアの仕事である。