序章：なぜあなたのWordPressは、スケールした途端にデータベースの悲鳴を聞くのか
コードレビューをしていて、最も背筋が凍る瞬間の一つがこれだ。数百万レコードを抱える `wp_postmeta` や `wp_posts` に対して、何の躊躇もなく `LIKE ‘%keyword%’` を投げ、さらにサードパーティ製プラグインが我が物顔で追加した野良インデックスが乱立している状態。
「なぜか最近、CPU使用率が100%に張り付く」
「商品数やカスタム投稿が10万件を超えたあたりから、管理画面の非同期リクエストがタイムアウトする」
原因の多くは、WordPressのデータベーススキーマ、特にメタデータ構造の物理特性を無視したクエリと、無秩序に肥大化したインデックス（Indexes）にある。
WordPressのコアは汎用性を重視している。その代償として、`wp_postmeta` のようなEAV（Entity-Attribute-Value）モデルを採用したテーブルは、デフォルトの状態ですら巨大なクエリプランナーの負荷を抱えている。そこに「検索性を上げるため」と称して素人が追加したインデックスが加わると、書き込み（INSERT/UPDATE/DELETE）のたびにB-Treeの再構築コストが雪だるま式に膨れ上がり、データベースのI/Oを完全に破壊する。
本稿では、データベースの内部構造とMySQLのオプティマイザの挙動を深く理解したエンジニアに向けて、不要なインデックスを特定し、書き込み性能と読み取り性能を極限まで両立させるための「インデックス再構築のプロフェッショナル戦略」を伝授する。
—
1. WordPressデータベーススキーマの暗部：`wp_postmeta` の物理構造とインデックスの罠
まずは敵を知ることから始めよう。`wp_postmeta` のデフォルトのスキーマ定義を確認する。
CREATE TABLE wp_postmeta (
meta_id bigint(20) unsigned NOT NULL auto_increment,
post_id bigint(20) unsigned NOT NULL default ‘0’,
meta_key varchar(255) default NULL,
meta_value longtext,
PRIMARY KEY (meta_id),
KEY post_id (post_id),
KEY meta_key (meta_key(191))
) ENGINE=InnoDB;
ここでエンジニアとして見逃してはならないポイントがある。`meta_key` に対するプレフィックスインデックス `KEY meta_key (meta_key(191))` だ。UTF8mb4環境において、インデックスの最大バイト数制限（767バイト）を回避するために191文字で切られている。
プラグインがもたらす「インデックス汚染」
多くのプラグイン（EC系、予約システム、カスタムフィールド系など）は、アクティベーション時に次のようなALTER TABLEを勝手に実行する。
— 最悪なアンチパターン例
ALTER TABLE wp_postmeta ADD INDEX meta_value_idx (meta_value(191));
`longtext` 型のカラムに対してプレフィックスインデックスを貼る行為は、書き込みパフォーマンスにおけるテロ行為に等しい。`meta_value` が更新されるたびにMySQLはインデックスツリー全体を再構築し、トランザクションログ（Redoログ）を圧迫する。さらに、`longtext` のプレフィックスインデックスはカーディナリティ（値の分散度）が低いことが多く、オプティマイザが誤った実行計画（フルテーブルスキャン）を選択する原因になる。
—
2. 診断：使われていないインデックスと冗長なインデックスの特定
プロダクション環境にメスを入れる前に、まず現在のデータベースの健康状態を定量的に測定する。MySQLのパフォーマンススキーマ（Performance Schema）を利用して、どのインデックスが「使われていないか」を暴くクエリを実行せよ。
SELECT
object_schema AS database_name,
object_name AS table_name,
index_name
FROM
performance_schema.table_io_waits_summary_by_index_usage
WHERE
object_schema = DATABASE()
AND object_name = ‘wp_postmeta’
AND index_name IS NOT NULL
AND count_star = 0;
このクエリの結果、`count_star = 0`（一度もオプティマイザに使用されていない）のインデックスが存在する場合、それは即座に削除（DROP）すべき負債である。
—
3. 実装：安全かつ堅牢なインデックス最適化・メンテナンスパイプライン
データベースのメンテナンスを場当たり的なSQLの直打ちで行うのは、プロの仕事ではない。WordPressのデプロイメントプロセスやマイグレーションスクリプトに組み込める、堅牢なPHPコードによるインデックス最適化の設計パターンを提示する。
以下のコードは、不要なインデックスの安全な削除と、頻繁に使用される複合インデックス（Composite Index）の最適配置をプログラム制御で行うプロダクションコードである。
/
if ( ! defined( ‘ABSPATH’ ) ) {
exit;
}
class WP_DB_Index_Optimizer {
/
- 削除対象となる「有害なプラグイン製インデックス」のホワイトリスト（部分一致）
/
private static array $blacklisted_indexes = [
‘meta_value_idx’,
‘custom_search_idx’,
‘plugin_meta_val_key’,
];
/
- 最適化プロセスの実行
- WP-CLIまたは管理者権限のフックから安全に呼び出す
/
public static function execute_optimization(): void {
global $wpdb;
$table_name = $wpdb->postmeta;
// トランザクション内で安全にDDLを実行（ストレージエンジンがInnoDBであることを前提）
// ※注意: MySQLではALTER TABLEは暗黙のコミットを引き起こすが、情報スキーマの整合性担保として記述
self::drop_redundant_indexes( $table_name );
self::ensure_optimal_composite_index( $table_name );
// テーブルの断片化解消（高負荷時はメンテナンスウィンドウで実行すること）
$wpdb->query( “OPTIMIZE TABLE {$table_name}” );
error_log( ‘[DB Optimizer] wp_postmeta index optimization completed successfully.’ );
}
/
- 不要なインデックスの安全なドロップ
/
private static function drop_redundant_indexes( string $table_name ): void {
global $wpdb;
// 現在のインデックス一覧を取得
$indexes = $wpdb->get_results( “SHOW INDEX FROM {$table_name}” );
$existing_indexes = [];
foreach ( $indexes as $index ) {
$existing_indexes[ $index->Key_name ] = true;
}
foreach ( self::$blacklisted_indexes as $target_index ) {
if ( isset( $existing_indexes[ $target_index ] ) ) {
//プリペアドステートメントは識別子（テーブル名・カラム名）に使えないためホワイトリスト検証済み変数を使用
$sql = “ALTER TABLE {$table_name} DROP INDEX `{$target_index}`”;
$result = $wpdb->query( $sql );
if ( false === $result ) {
error_log( “[DB Optimizer Error] Failed to drop index: {$target_index}” );
} else {
error_log( “[DB Optimizer] Successfully dropped redundant index: {$target_index}” );
}
}
}
}
/
- 高速なメタ検索のためのカバリング（複合）インデックスの構築
- (post_id, meta_key) の順序がWordPressのクエリにおいて最もヒット率が高い
/
private static function ensure_optimal_composite_index( string $table_name ): void {
global $wpdb;
$index_name = ‘idx_postid_metakey’;
// 既に存在するか確認
$exists = $wpdb->get_var( $wpdb->prepare(
“SELECT COUNT(1) FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = DATABASE()
AND TABLE_NAME = %s
AND INDEX_NAME = %s”,
$table_name,
$index_name
) );
if ( ! $exists ) {
// 単一の post_id インデックスと meta_key インデックスが存在する場合、
// (post_id, meta_key) の複合インデックスに統合することでストレージとCPU負荷を軽減する
$sql = “ALTER TABLE {$table_name} ADD INDEX `{$index_name}` (`post_id`, `meta_key`(191))”;
$result = $wpdb->query( $sql );
if ( false === $result ) {
error_log( “[DB Optimizer Error] Failed to create composite index: {$index_name}” );
} else {
error_log( “[DB Optimizer] Successfully created composite index: {$index_name}” );
}
}
}
}
// WP-CLIコマンドとしての登録（実運用での安全なバッチ実行のため）
if ( defined( ‘WP_CLI’ ) && WP_CLI ) {
WP_CLI::add_command( ‘db optimize-meta’, function() {
WP_CLI::line( ‘Starting wp_postmeta index optimization…’ );
WP_DB_Index_Optimizer::execute_optimization();
WP_CLI::success( ‘Database optimization routine finished.’ );
} );
}
—
4. なぜ `(post_id, meta_key)` の複合インデックスが究極の武器になるのか
上記のコード内で生成している `(`post_id`, `meta_key`(191))` という複合インデックスについて、データベースの内部挙動の観点から解説する。
WordPressで最も頻繁に発行されるクエリの代表格がこれだ：
SELECT meta_value FROM wp_postmeta WHERE post_id = 12345 AND meta_key = ‘_price’;
もしインデックスが `post_id` 単体、`meta_key` 単体に分かれている場合、MySQLは以下のいずれかの非効率な処理を選択せよと迫られる。
1. `post_id` で絞り込んでから、該当する行を `meta_key` でフィルタリングする（Index Mergeのオーバーヘッド）。
2. どちらか一方だけインデックスを使い、残りはメモリ上または一時テーブルでスキャンする。
しかし、左端プレフィックスの法則（Leftmost Prefix Property）に基づき `(post_id, meta_key)` という複合インデックスが存在する場合、MySQLはB-Treeをひと舐めするだけでダイレクトに該当レコードの物理アドレスに到達できる。
さらに、不要な `meta_value` のインデックスを排除しているため、`INSERT INTO wp_postmeta` 時のB-Treeノード分裂（Page Split）の頻度が劇的に低下し、書き込みスループット（TPS）が最大で300%以上向上するケースも珍しくない。
—
終わりに：エンジニアが守るべきデータベースの美学
WordPressは「誰でも簡単に使えるCMS」であるゆえに、内部のデータベース層がどれほど繊細なバランスの上に成り立っているかを見落とされがちだ。プラグインが勝手に生やすインデックスや、場当たり的なSQLチューニングは、一時的な延命措置にすぎない。
システムの根幹を掌握するエンジニアとして、スキーマの物理構造を正しく理解し、クエリプランナーの思考をトレースし、無駄なコードやインデックスを容赦なく削ぎ落とすこと。それこそが、何百万アクセスの高負荷に耐えうる真に堅牢なWordPressシステムを構築唯一の道である。