WordPressデータベースの深淵：wp_postmetaへのインデックス追加と「書き込み性能」の非情なトレードオフ
WordPressの `wp_postmeta` テーブルを覗いたことはあるか？
`meta_key` カラムにインデックスがない初期状態では、`get_posts` でのメタクエリはフルテーブルスキャンに近い挙動を示し、データが数百万件を超えた瞬間、サイトは膝を折る。
多くのエンジニアがここで「とりあえず `meta_key` にインデックスを貼る」という安直な解を出す。だが、これは諸刃の剣だ。MySQLのB-treeインデックスは読み取りを加速させる代わりに、書き込み（INSERT/UPDATE）のコストを指数関数的に増大させる。
今日は、この「インデックスの魔物」をどう飼いならし、システムを堅牢に保つか、その技術的指針を伝授する。
—
1. なぜ `wp_postmeta` のインデックスが「諸刃の剣」なのか
`wp_postmeta` は EAV（Entity-Attribute-Value）モデルを採用している。この構造の最大の弱点は、1つのエンティティ（投稿）が複数の行に分散して保存されることだ。
- 読み取り時: 結合や検索条件に `meta_key` が使われるため、インデックスがないとDBは全行をなめる。
- 書き込み時: インデックスが存在すると、レコードが追加・更新されるたびに、MySQLはB-treeを再構築（あるいはノード分割）する必要がある。
特に、高頻度で更新が発生するカスタム投稿タイプや、外部APIから同期されるデータ構造において、インデックスの過剰な追加は `INSERT` 処理を著しく劣化させ、DBロックの競合を引き起こす。
—
2. インデックス設計の鉄則：複合インデックスとカーディナリティ
単一の `meta_key` だけにインデックスを貼るのは素人の設計だ。WordPressのクエリは通常 `meta_key` と `meta_value` のペア、あるいは `post_id` との組み合わせで走る。
推奨されるインデックス設計（SQL）
— meta_key だけではなく、頻繁に使用される複合インデックスを考慮する
CREATE INDEX idx_meta_key_value ON wp_postmeta (meta_key(191), meta_value(191));
※MySQLのutf8mb4環境ではインデックス長の制限があるため、191文字に抑えるのが定石だ。
—
3. 堅牢な設計パターン：コードによる最適化
インデックスだけに頼る設計は脆弱だ。WordPressの内部APIをハックし、クエリそのものを最適化する実装こそが、真のエンジニアリングである。
実務で使うべき「インデックスに依存しない」検索最適化例
`meta_query` で重いクエリを発行する代わりに、検索に必要なデータだけをフラットなカスタムテーブルに抽出する。これが「スケールするWordPress」の正攻法だ。
/
- 独自テーブルへメタデータを同期する（書き込み負荷を分散させる）
- wp_postmetaへの直接クエリを避け、読み取り専用テーブルを構築する
/
function sync_custom_meta_to_flat_table($post_id) {
global $wpdb;
// 非同期処理やトランザクションを検討すべきタイミング
$meta_key = ‘subscription_status’;
$meta_value = get_post_meta($post_id, $meta_key, true);
// wp_postmetaを直接叩くのではなく、専用テーブルに射影する
$wpdb->replace(
“{$wpdb->prefix}custom_search_index”,
[
‘post_id’ => $post_id,
‘meta_key’ => $meta_key,
‘meta_value’ => $meta_value,
‘updated_at’ => current_time(‘mysql’)
],
[‘%d’, ‘%s’, ‘%s’, ‘%s’]
);
}
// 保存時にフックするが、大規模サイトならAction Scheduler等で非同期実行すること
add_action(‘save_post’, ‘sync_custom_meta_to_flat_table’);
—
4. パフォーマンス測定の心構え
「なんとなく速くなった」という感覚はエンジニアの敵だ。必ず `SAVEQUERIES` 定数と `Query Monitor` プラグインを使用して、以下の数値を計測せよ。
1. Index Cardinality（カーディナリティ）: `SHOW INDEX FROM wp_postmeta` で確認せよ。値が低いインデックスは無意味なオーバーヘッドを生むだけだ。
2. Lock Wait Time: `SHOW ENGINE INNODB STATUS` を叩き、更新処理がロック待ちを起こしていないか監視せよ。
3. Explain Plan: `EXPLAIN SELECT …` で、インデックスが正しく効いているか（Typeが `ref` や `const` になっているか）を確認せよ。
—
エンジニアへの問い
インデックスを追加するかどうかを迷ったとき、「このデータは本当に `wp_postmeta` に置くべきか？」と自問自答してほしい。
もしそのデータが検索の軸になるのであれば、`wp_postmeta` は「ゴミ箱」ではなく、正規化された別テーブルへ移行すべきだ。インデックスの微調整で延命するのか、アーキテクチャの変更で根本解決するのか。
システムは嘘をつかない。 データベースの構造こそが、そのサイトの未来を規定するのだ。次回のコードレビューでは、この視点を持って臨んでほしい。