【入門編】初心者向け：管理画面の投稿一覧が重い時に確認すべきインデックスの基礎知識 – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

こんにちは。WordPressの深淵へようこそ。

管理画面の「投稿一覧」を開くたびに、プログレスバーがゆっくりと進む様子を眺めて、もどかしい思いをしたことはありませんか？
「コンテンツが増えたから仕方ない」と諦めるのは、まだ早いです。実はそれ、データベースの「道案内」がうまく機能していないだけかもしれません。

今日は、WordPressの心臓部である `wp_posts` テーブルの構造を紐解き、なぜクエリが遅くなるのか、そしてどうすれば爆速にできるのかを、エンジニアの視点で解説します。

—

1. なぜ「投稿一覧」は重くなるのか？

WordPressの管理画面で投稿一覧を表示する際、裏側では `WP_Query` が次のようなSQLを発行しています（簡略化しています）。

SELECT FROM wp_posts
WHERE post_type = ‘post’
ORDER BY post_date DESC
LIMIT 20 OFFSET 0;

このクエリが走るとき、MySQLはテーブル全体をスキャン（全件走査）しようとします。1,000件程度なら一瞬ですが、10万件を超えるとどうなるでしょう？MySQLは「どの投稿が最新か」を探すために、膨大なデータを上から順に読み込んでいくことになります。

ここで登場するのが「インデックス（索引）」です。

—

2. インデックスは「辞書の巻末」と同じ

辞書で特定の単語を探すとき、最初からページをめくる人はいないですよね？巻末の索引を見て、何ページにあるかを確認するはずです。

データベースのインデックスも全く同じです。`wp_posts` テーブルにはデフォルトでいくつかのインデックスが貼られていますが、特定の条件（カスタムステータスや複雑なソートなど）が加わると、標準のインデックスだけでは足りなくなります。

`wp_posts` の主要なインデックス構造（イメージ）

WordPressは標準で `type_status_date` という複合インデックスを持っています。これは「投稿タイプ」と「ステータス」で絞り込み、「日付」で並び替える処理を高速化するためのもの。これがあるおかげで、デフォルトの投稿一覧は高速に動作しているんです。

—

3. なぜクエリは「迷子」になるのか？

よくある「重くなる原因」は、このインデックスを無視した検索条件を加えてしまうことです。

例えば、以下のようなコードを `pre_get_posts` フックで書いたとしましょう。

add_action( ‘pre_get_posts’, ‘my_custom_query_filter’ );
function my_custom_query_filter( $query ) {
if ( is_admin() && $query->is_main_query() ) {
// meta_valueで絞り込むと、インデックスが効かなくなることが多い
$query->set( ‘meta_key’, ‘is_featured’ );
$query->set( ‘meta_value’, ‘1’ );
}
}

このコードを実行すると、WordPressは `wp_postmeta` テーブルとの結合（JOIN）を強制されます。`wp_postmeta` に `meta_key` や `meta_value` のインデックスが適切に貼られていない場合、データベースは悲鳴を上げます。

陥りやすい罠：文字列検索のコスト

`meta_value` は `LONGTEXT` 型です。ここにインデックスを貼ることは可能ですが、長すぎる文字列はインデックスサイズを肥大化させ、逆にパフォーマンスを落とします。

—

4. 現場で使える改善のヒント

もし管理画面が遅いと感じたら、まずは以下のステップを試してください。

1. クエリモニター（Query Monitor）を使う
プラグイン「[Query Monitor](https://ja.wordpress.org/plugins/query-monitor/)」をインストールしてください。どのクエリが遅いのか、何秒かかっているのかが可視化されます。これがエンジニアの必須ツールです。
2. 不要なJOINを避ける
`meta_query` を多用していませんか？もしメタデータで絞り込む必要があるなら、専用のカスタムテーブルを作るか、タクソノミー（カテゴリやタグ）で表現できないか検討してください。タクソノミーはインデックスが非常に効きやすい構造になっています。
3. インデックスの追加を検討する（上級編）
特定のカラムで頻繁にフィルタリングしているなら、MySQL側で直接インデックスを追加するのも手です。

— 例：post_type と post_status の組み合わせで検索が多い場合
CREATE INDEX idx_type_status ON wp_posts (post_type, post_status);

※ただし、むやみにインデックスを増やすと、投稿保存時の書き込み速度（INSERT/UPDATE）が低下するので注意が必要です。

—

最後に：WordPressは「育て方」で化ける

WordPressは、デフォルトの状態では「誰にでも使いやすい」ようにチューニングされています。しかし、データが数万件、数十万件と増えていくと、その「汎用的な設計」がボトルネックになることがあります。

今回解説した「インデックスの意識」を持つだけで、あなたはただの利用者から、システム全体を俯瞰できるエンジニアへと一歩近づけました。

「なぜ遅いのか」をデータベースの裏側から想像する。その癖さえつけば、どんな大規模なサイトでも余裕を持って扱えるようになりますよ。

ここをクリアすれば、WordPressの基本はもうバッチリです。次はぜひ、`wp_postmeta` のデータ構造についても深く掘り下げてみてください。応援しています！