こんにちは！WordPressの裏側の仕組みやデータベースの挙動に興味を持ってこのページにたどり着いたのですね。素晴らしい着眼点です！
他の言語（Ruby、Python、Node.jsなど）からWordPressの世界へやってくると、誰もが一度は通る壁があります。そう、「なぜかデータが増えてくるとサイトが重くなる」という現象です。
今回は、WordPressの心臓部であるデータベース、特に`wp_posts`テーブルのインデックス構造にメスを入れます。「`WP_Query`の内部で何が起きているのか」「なぜデフォルトのインデックスだと遅くなるのか」、そして「どうすれば爆速にできるのか」を、優しく紐解いていきましょう。
ここをクリアすれば、あなたも単なる「WordPressの使い方を知っている人」から、「WordPressのシステムを意のままに操るエンジニア」への大きな一歩を踏み出せますよ。バッチリマスターしていきましょう！
—
1. WordPressの心臓部：`wp_posts`テーブルの現実を知ろう
WordPressで投稿、固定ページ、カスタム投稿タイプ、さらにはメディアの添付ファイルまで、すべての「コンテンツの器」が保存されるのが`wp_posts`テーブルです。
サイトの規模が大きくなると、このテーブルのレコード数は数万、数十万件に膨れ上がります。ここで、普段私たちが何気なく書いている次のようなコードを思い出してください。
// 例：特定のカスタム投稿タイプ「event」の一覧を取得する
$args = array(
‘post_type’ => ‘event’,
‘post_status’ => ‘publish’,
posts_per_page => 10,
);
$query = new WP_Query( $args );
この瞬間、WordPressの内部（`WP_Query`クラス）では、データベースに対して次のようなSQLが発行されています。
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
WHERE 1=1
AND wp_posts.post_type = ‘event’
AND wp_posts.post_status = ‘publish’
ORDER BY wp_posts.post_date DESC
LIMIT 0, 10;
一見、何の問題もないシンプルなクエリに見えますよね。しかし、データベースの内部（MySQL/MariaDB）の動きを覗いてみると、思わぬボトルネックが隠されています。
—
2. なぜデフォルトのインデックスでは限界が来るのか？
データベースのインデックス（索引）は、本でいう「巻末の索引ページ」のようなものです。これがないと、MySQLは条件に合う行を探すために、テーブルの最初から最後までをすべて目視で確認する「フルテーブルスキャン（全件走査）」を行ってしまいます。
デフォルトのインデックス構成
デフォルトのWordPress（初期状態）の`wp_posts`テーブルには、次のようなインデックスが貼られています。
- `PRIMARY KEY` (ID)
- `KEY type_status_date` (post_type, post_status, post_date) など、バージョンや環境により異なりますが、単一の列や独立したインデックスが主です。
ここで問題になるのが、「特定のカスタム投稿タイプが膨大に存在する場合」です。
例えば、`wp_posts`に100万件のデータがあり、そのうち95万件が「商品（`product`）」というカスタム投稿タイプ、残りの5万件があなたが運営する「イベント（`event`）」だとします。
先ほどのクエリ（`post_type = ‘event’` 且つ `post_status = ‘publish’`）を処理するとき、もしMySQLのオプティマイザーが「`post_type`のインデックス」をうまく使えなかったり、単一カラムのインデックスしかなかったりすると、以下のような非効率なスキャンが発生します。
1. `post_type`だけで絞り込もうとするが、インデックスの選択性（カーディナリティ：値の種類と偏り）が悪いため、結局大量の行をスキャンする羽目になる。
2. 結果として、ディスクI/Oが跳ね上がり、CPU使用率がスパイクし、ページの表示速度がガクッと落ちてしまいます。
—
3. 救世主：「複合インデックス（Composite Index）」の導入
この問題を鮮やかに解決するのが、複数のカラムを組み合わせた「複合インデックス」です。
今回のケースで最も効果を発揮するのは、`post_type` と `post_status` をペアにした複合インデックスです。さらに、`ORDER BY`で使われている `post_date` も含めると、クエリの処理速度は劇的に向上します。
実際にインデックスを追加してみよう（SQL）
開発環境やphpMyAdminなどのデータベース管理ツールを使い、`wp_posts`テーブルに新しい複合インデックスを追加するSQLは以下のようになります。
— post_type と post_status, そして post_date を網羅する複合インデックスを追加
ALTER TABLE wp_posts
ADD INDEX idx_post_type_status_date (post_type(20), post_status(20), post_date);
> 💡 ワンポイントアドバイス（プレフィックス長について）
> `post_type`や`post_status`は文字列（VARCHAR）なので、MySQLでインデックスを作成する際に文字数制限（プレフィックス長）を指定することがあります（例: `post_type(20)`）。これにより、インデックスのサイズを小さく抑え、メモリ効率を上げることができます。
この複合インデックスがなぜ速いのか？
データベースは、インデックスを「辞書順」に並べて保持します。
複合インデックス `(post_type, post_status, post_date)` を作成すると、データベース内部では次のようにデータが整理されます。
1. まず `post_type`（例: `event`）で綺麗にまとめられる。
2. その同じ `post_type` の中で、さらに `post_status`（例: `publish`）ごとに整列される。
3. 最後にその中で `post_date` の順に並ぶ。
そのため、MySQLは一瞬で該当するデータの「開始位置」と「終了位置」を特定し、余計な行を一切見ることなく（＝シークすることなく）必要なデータだけをピンポイントで取得できるようになるのです。これがインデックスチューニングの醍醐味です！
—
4. 陥りがちな罠と注意すべきポイント
「じゃあ、すべてのカラムに複合インデックスを貼ればいいんだ！」と思ったそこのあなた。ちょっと待ってくださいね。ここに実務でやりがちな大きな罠があります。
⚠️ 注意点1: 書き込み（INSERT/UPDATE）のパフォーマンス低下
インデックスは、データを「読む（SELECT）」ときには爆速にしてくれますが、新しい投稿を追加したり（`wp_insert_post`）、更新したり（`wp_update_post`）するときには、インデックス自体も毎回書き換える必要があります。
そのため、インデックスを増やしすぎると、今度は「記事の保存や公開にやたら時間がかかる」という別のトラブルを引き起こします。
⚠️ 注意点2: クエリの「WHERE句の順番」とインデックスの順序
MySQLの複合インデックスは、左側から順番に条件が一致していなければ効果を発揮しません。
例えば、インデックスを `(post_type, post_status)` で作った場合、SQLの検索条件が `WHERE post_status = ‘publish’ AND post_type = ‘event’` であっても、MySQLのオプティマイザーが賢く順序を入れ替えてくれることが多いですが、基本的にはインデックスを作った順番通りに条件を指定するのが最も確実で安全です。
`WP_Query`を発行する際も、このデータベースの構造を意識して引数を渡す癖をつけておくと、大規模サイトでもびくともしない堅牢な設計ができるようになりますよ。
—
5. まとめ
いかがでしたでしょうか？ 今回は、中級者へのステップアップとして以下のポイントを解説しました。
1. `wp_posts`の膨張とデフォルトクエリの挙動を知る。
2. 大量のカスタム投稿タイプがある環境では、単一インデックスでは限界が来る理由を理解する。
3. `post_type` と `post_status` （＋ `post_date`）の複合インデックスがなぜ劇的な効果を生むのかを知る。
4. 読み込み速度と書き込み負荷のトレードオフ（バランス）を意識する。
WordPressは、PHPのコードを書くだけでなく、その下にあるデータベース（MySQL）がどう動いているかをイメージできるようになると、見える景色がガラリと変わります。
「なんとなく動くコード」から「内部構造を理解した美しいコード」へ。
ここをクリアしたあなたなら、どんなに巨大なWordPress案件が来てももう怖くありません。自信を持って、次の開発に挑んでくださいね！