こんにちは！WordPressの裏側の仕組みやデータベースの挙動に興味を持ってくれて嬉しいです。
他の言語（Ruby、Python、Node.jsなど）からWordPressに入ってきた開発者によくあるのが、「管理画面でポチポチ作っていたら、気づいた時にはサイトが重くなっていた」というトラブルですよね。
今回は、WordPressのパフォーマンスチューニングにおいて避けて通れない、`wp_term_relationships` テーブルの肥大化とタクソノミー設計の極意を解説します。ここをクリアすれば、データベースのボトルネックを見抜けるワンランク上のエンジニアになれますよ。一緒に本質をマスターしていきましょう！
—
1. なぜ `wp_term_relationships` は魔窟になりやすいのか？
WordPressのデータベース構造を思い出してください。投稿（Post）とカテゴリーやタグ（Term）の関係性は、多対多（Many-to-Many）の構造をとっています。これを仲介しているのが、他でもない `wp_term_relationships` テーブルです。
このテーブルの構造は極めてシンプルです。
- `object_id`（投稿IDなど）
- `term_taxonomy_id`（タクソノミーID）
- `term_order`（並び順）
「これだけシンプルなら高速なはずでは？」と思いますよね。実はここに落とし穴があります。
データの爆発的増加（Data Explosion）
例えば、以下のような設計をしたとします。
- 1つの投稿に「ブランド」「カラー」「サイズ」「カテゴリ」「タグ」など、合計10個のタクソノミーを紐付ける。
- これが10万記事蓄積される。
計算してみてください。
$$10万記事 \times 10個の紐付け = 100万行$$
たった10万件の投稿でも、リレーションの数だけ `wp_term_relationships` の行数は爆発的に増加します。これが数百万件規模になると、MySQL（InnoDB）のB-Treeインデックスがキャッシュに乗り切らなくなり、ディスクI/Oが跳ね上がってクエリがスローダウンするのです。
—
2. WP_Queryが発行する「重いSQL」の正体
中級者へのステップアップとして、私たちが普段何気なく書いている `WP_Query` が裏で何をやっているかを見てみましょう。
例えば、「特定の複数のタグを持つ最新の投稿を取得したい」という要件で、以下のようなコードを書いたとします。
‘post’,
‘posts_per_page’ => 10,
‘tax_query’ => array(
array(
‘taxonomy’ => ‘post_tag’,
‘field’ => ‘slug’,
‘terms’ => array( ‘php’, ‘wordpress’, ‘performance’ ),
‘operator’ => ‘AND’,
),
),
);
$query = new WP_Query( $args );
このコード、一見なんの問題もなさそうですが、内部で発行される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_relationships AS tr2 ON (wp_posts.ID = tr2.object_id)
INNER JOIN wp_term_relationships AS tr3 ON (wp_posts.ID = tr3.object_id)
WHERE 1=1
AND ( tr1.term_taxonomy_id = 12 )
AND ( tr2.term_taxonomy_id = 34 )
AND ( tr3.term_taxonomy_id = 56 )
AND wp_posts.post_type = ‘post’
AND wp_posts.post_status = ‘publish’
GROUP BY wp_posts.ID
ORDER BY wp_posts.date DESC
LIMIT 0, 10;
【ここがポイント！】
`tax_query` で `operator` に `AND` を指定すると、条件の数だけ `wp_term_relationships` テーブルとの自己結合（Self-Join） が発生します。
テーブルの行数が数百万件ある状態でこの自己結合が走ると、MySQLのオプティマイザが悲鳴を上げ、実行計画（EXPLAIN）の効率が最悪な状態になってしまうのです。
—
3. 肥大化を防ぐためのタクソノミー設計の極意
では、このデータベースの悲鳴を未然に防ぐにはどうすればよいでしょうか？ 実装の現場で使える3つのアプローチを授けます。
① 「タクソノミーにすべきもの」と「メタデータにすべきもの」を見極める
何でもかんでもカスタムタクソノミーとして実装するのはアンチパターンです。
- タクソノミーに向いているもの:
- 記事を階層構造で分類したい（カテゴリ）
- ユーザーが横断的にアーカイブページを行き来する（タグ、地域など）
- メタデータ（`wp_postmeta`）に向いているもの:
- 単なる「状態」や「数値」（例：公開ステータス、閲覧数、在庫数）
- 1つの投稿に対して値が1つしかなく、検索で横断的なアーカイブを必要としないもの
「とりあえずタグっぽくしたいからタクソノミーにしよう」という安易な判断が、`wp_term_relationships` を肥大化させる最大の原因になります。
② 不要なタームの紐付けを生まない設計（データの正規化）
例えば、ECサイトで商品を扱う際、「色」や「サイズ」をすべてWordPressの標準タクソノミーで表現すると、組み合わせの数だけリレーションが増えます。
何万点ものSKU（在庫単位）を持つサイトであれば、タクソノミーではなく、カスタムテーブル（WPとは別個の独立したテーブル）を切るか、JSON形式でシリアライズして `wp_postmeta` に持たせる方が、リレーショナルデータベースへの負荷を劇的に下げられるケースがあります。
③ 複合インデックスの理解と最適化（データベース層）
もし、どうしても `wp_term_relationships` が巨大化してしまう場合は、MySQLのインデックスチューニングが必要です。
デフォルトの `wp_term_relationships` には、主キー（`object_id`, `term_taxonomy_id` の複合）のほかに、`term_taxonomy_id` 単体のインデックスが存在します。
しかし、特定のクエリパターンによっては、MySQLがうまくインデックスを選択できないことがあります。
実務でデータベースサーバーに直接アクセスできる権限がある場合は、クエリの実行計画（`EXPLAIN`）を必ず確認し、必要に応じて次のような追加インデックスを検討します。
— object_id と term_taxonomy_id の順序を意識した複合インデックスの確認・最適化
— ※WordPressコアテーブルの構造を直接変更する際はバックアップと十分な検証を行ってください
ALTER TABLE wp_term_relationships ADD INDEX idx_taxonomy_object (term_taxonomy_id, object_id);
このインデックスがあることで、`term_taxonomy_id` で絞り込んだあとの `object_id` の参照が劇的に高速化されます。
—
4. 現場で役立つ！効率的なクエリを書くための実践知見
最後に、PHPサイドでパフォーマンスを守るための実用的なテクニックを紹介します。
`no_found_rows => true` を活用する
先ほどのSQLに `SQL_CALC_FOUND_ROWS` という記述があったのにお気づきですか？
これは「ページネーションのために、LIMIT句を無視して総件数を数える」というWordPressの親切機能ですが、データベース全体のスキャンを伴うため、データ量が増えると確実にパフォーマンスの足かせになります。
もしページネーション（「全何ページ中、何ページ目」という表示）が不要なループであれば、必ず以下の設定を入れてください。
‘post’,
‘posts_per_page’ => 10,
‘no_found_rows’ => true, // ★ここで SQL_CALC_FOUND_ROWS を無効化して爆速化！
);
$query = new WP_Query( $args );
たったこれだけの記述で、MySQLの内部処理が劇的に軽くなります。
—
まとめ
いかがだったでしょうか？
- `wp_term_relationships` は投稿とタームを繋ぐ仲介役であり、多対多ゆえに肥大化しやすい。
- `tax_query` の `AND` 検索は自己結合を引き起こし、クエリ遅延の原因になる。
- 何でもタクソノミーにせず、メタデータや適切な設計・インデックスチューニングを組み合わせる。
- 不要なときは `no_found_rows => true` で無駄なクエリ負荷を取り除く。
ここをクリアできれば、数百万規模の投稿を抱える大規模メディアサイトでも、ビクともしない堅牢なWordPressシステムを構築できるようになります。
基礎から一歩進んだこのデータベースの構造と最適化の視点、ぜひ実際の開発現場で役立ててくださいね。応援しています！