こんにちは！WordPressの裏側の仕組みやデータベースの挙動に興味を持ってこのブログに辿り着いたのですね。素晴らしい着眼点です！
他の言語（例えばRuby on RailsやLaravelなど）からWordPressの世界に入ってきた開発者の多くが、「なんだかWordPressって、データが増えてくると急に管理画面やフロントエンドが重くなるな…」と感じる瞬間があります。
その原因の多くは、データベースの心臓部である`wp_posts`テーブルの検索効率、そしてMySQLのクエリプランナー（オプティマイザ）がどう動いているかを知らないことにあります。
今回は、WordPressのデータベース設計における超重要ポイントである「`post_status`と`post_type`の複合インデックス」について、MySQLの内部挙動を覗き見しながら、優しく丁寧に解説していきますね。ここをクリアすれば、データベースチューニングの基礎はバッチリマスターできますよ！
—
1. WordPressのデータベース設計の現実を知ろう
WordPressのメインストレージである`wp_posts`テーブルには、投稿、固定ページ、添付ファイル、さらにはカスタム投稿タイプやリビジョン、ナビゲーションメニューに至るまで、あらゆる「コンテンツの器」がごちゃ混ぜに保存されています。
ここで、少しデータベースの構造をイメージしてみましょう。
[ wp_posts テーブルのイメージ ]
+—-+——————-+—————-+————-+
| ID | post_title | post_type | post_status |
+—-+——————-+—————-+————-+
| 1 | Hello world! | post | publish |
| 2 | Sample Page | page | publish |
| 3 | My Custom Post | my_portfolio | draft |
| 4 | Auto-save draft | revision | inherit |
+—-+——————-+—————-+————-+
何万件、何百万件というレコードがこの1つのテーブルに蓄積されていくわけです。
さて、ここで私たちが日常的に書くWordPressのクエリ（`WP_Query`や直接のSQL）を思い出してください。
「公開済みの通常の投稿（`post_type = ‘post’` かつ `post_status = ‘publish’`）を最新順で10件取得したい！」
このようなリクエストが飛んだとき、MySQLは裏側でどのようにデータを探しているのでしょうか？
—
2. インデックス（索引）ってなに？ なぜ「複合」が必要なの？
データベースのインデックスは、よく分厚い教科書の「巻末索引（インデックス）」に例えられます。索引がなければ、目的のページを探すために1ページ目からすべてをめくる（＝フルテーブルスキャン）羽目になり、膨大な時間がかかりますよね。
単一インデックスの限界
WordPressの標準状態では、`post_type` や `post_status` にそれぞれ個別のインデックスが貼られていることがあります。しかし、MySQLのオプティマイザ（賢い検索ルート案内人）は、「1回のクエリにつき、基本的には1つのテーブルにつき1つのインデックスしか使わない」という性質を持っています（※インデックスマージ等例外はありますが、高負荷時には非効率になりがちです）。
例えば、以下のようなSQLが実行されたとします。
SELECT FROM wp_posts
WHERE post_type = ‘post’
AND post_status = ‘publish’;
ここで `post_type` のインデックスだけを使うと、`post_type = ‘post’` に該当する数千〜数万件のデータを絞り込んだ後、その中から `post_status = ‘publish’` のものを1件ずつ目視で確認するような無駄が生じます。
救世主：複合インデックス（Composite Index）の力
そこで登場するのが、複数のカラムを組み合わせた「複合インデックス」です。
`post_type` と `post_status` をひとまとめにしたインデックスを作成すると、データベースの中では次のように綺麗に整頓された「電話帳」が作られます。
[ 複合インデックスのイメージ (post_type, post_status) ]
- post_type: page -> post_status: publish
- post_type: post -> post_status: publish <-- 一瞬でピンポイント特定！
- post_type: post -> post_status: draft
この順番（左側から順に絞り込む性質）でインデックスを設計しておくと、MySQLのクエリプランナーは迷うことなく秒速で目的のレコードに辿り着くことができるのです。
—
3. 実践！複合インデックスを追加してみよう
それでは、実際にデータベースへ複合インデックスを追加する手順を見ていきましょう。
※作業の前には、必ずデータベースのバックアップを取ってくださいね。
SQLによるインデックスの追加
phpMyAdminやターミナル（MySQLクライアント）から、以下のSQLを実行します。
— wp_postsテーブルに post_type と post_status の複合インデックスを追加する
ALTER TABLE wp_posts
ADD INDEX idx_type_status (post_type, post_status);
コードの意味
- `ALTER TABLE wp_posts`：`wp_posts` テーブルの構造を変更（アップデート）しますよ、という宣言です。
- `ADD INDEX idx_type_status`：`idx_type_status` という名前の新しいインデックスを追加します。
- `(post_type, post_status)`：左側（第一キー）に `post_type`、右側（第二キー）に `post_status` を配置した複合インデックスにします。
【重要なお作法】
なぜ `post_status, post_type` ではなく、`post_type, post_status` の順番にしたのでしょうか？
それは、WordPressサイトにおいて「まずは投稿タイプ（`post` なのか `page` なのか `custom_post` なのか）で大別され、その中でステータス（`publish` なのか `draft` なのか）が絞り込まれる」というカーディナリティ（データの多様性・選択度）の観点から、大まかな分類を左に置いた方が効率が良いからです。
—
4. 陥りやすい罠と文法・設計の注意点
初心者の方がよくやってしまう失敗や、パフォーマンスを逆に悪化させてしまうアンチパターンについても触れておきますね。
1. インデックスを貼りすぎない
「じゃあ、よく使うカラム全部に複合インデックスを貼っちゃえ！」というのはNGです。インデックスは読み込み（SELECT）を高速化する代わりに、記事の投稿・更新時（INSERT / UPDATE）の書き込み速度を犠牲にします。バランスが命です。
2. クエリの条件の順番に気をつける
MySQLの複合インデックスは、左側のカラム（今回の場合は `post_type`）を条件に含めていない場合、インデックスが効きにくくなるという性質があります（最左プレフィックス原則）。
`WHERE post_status = ‘publish’` だけの検索では、この複合インデックスは十分に活用されません。どのようなクエリを頻発するのかを分析した上でインデックスを設計しましょう。
—
5. まとめ
今回は `wp_posts` テーブルのパフォーマンスを劇的に改善するための「複合インデックス」の概念と設計方法について解説しました。
- WordPressの `wp_posts` は色々なデータが混在しているため、検索が重くなりがち。
- 頻出する条件（`post_type` と `post_status`）の組み合わせには、複合インデックスが絶大な効果を発揮する。
- カラムの並び順（左側をより大きな分類にする）を意識することが重要。
インデックスのチューニングは、Webアプリケーション全体のレスポンスを向上させるための非常にロジカルで楽しいアプローチです。大規模なメディアサイトや、カスタム投稿を多用するWebアプリケーションを構築する際には、ぜひこの知見を思い出してデータベース設計に活かしてみてくださいね。
あなたのWordPress開発ライフが、より一層深みのある素晴らしいものになりますように！