WordPressの深淵：`wp_postmeta` EAVモデルにおけるインデックスの呪縛と最適化戦略
WordPressのデータベース設計を語る上で避けて通れないのが、`wp_postmeta`テーブルが採用しているEAV（Entity-Attribute-Value）モデルだ。柔軟性は高いが、スケーリングにおいて最も「毒」になりやすい部分でもある。
今日は、メタキー（Attribute）のカーディナリティ（値の重複度合い）がMySQLの実行計画にどう影響し、なぜあなたのクエリが本番環境で「死ぬ」のかを、コアコントリビューターの視点から解剖する。
—
1. なぜ `wp_postmeta` は「クエリの墓場」になるのか
`wp_postmeta`は以下の構造を持つ。
— 基本的な構造
+———+———+———–+———-+
| meta_id | post_id | meta_key | meta_value |
+———+———+———–+———-+
このテーブルには `(post_id, meta_key)` に複合インデックスが貼られている。しかし、ここには致命的な罠がある。
オプティマイザを迷わせる「カーディナリティの偏り」
MySQLのオプティマイザは、統計情報に基づいてインデックスの使用可否を判断する。もし、`meta_key`の種類が数千を超え、特定のキー（例：`_is_processed`）が全行の99%を占めている場合、MySQLは「インデックスを使うよりフルスキャンした方が速い」と判断し、インデックスを無視する挙動を見せる。
これが、特定のメタキーで検索した瞬間にDB負荷がスパイクする真因だ。
—
2. EXPLAINによる深層分析
あなたが書いた `get_posts()` や `WP_Query` が、バックグラウンドでどのような `EXPLAIN` を生んでいるか想像したことはあるか？
EXPLAIN SELECT post_id FROM wp_postmeta WHERE meta_key = ‘complex_key_with_high_cardinality’ AND meta_value = ‘target_value’;
もし、インデックスが `(meta_key, meta_value(20))` のように貼られていない場合、オプティマイザは `meta_key` で絞り込んだ後の膨大な `meta_value` をメモリ上でフィルタリングする。これはディスクI/Oを激増させる。
—
3. 実践：高負荷を回避するプロダクションコードの設計
`WP_Query` に頼り切るのではなく、メタデータの特性に応じたアクセスパターンを構築する必要がある。
パターンA：メタデータの分離（カスタムテーブルの活用）
カーディナリティが高い（メタキーの種類が多い）かつ、検索対象となるメタデータなら、`wp_postmeta`から切り出し、専用のテーブルを作るのが正解だ。
/
- 独自テーブルへデータを同期する堅牢な実装
- 外部キー制約を担保しつつ、メタデータをフラットに保持する
/
add_action(‘save_post’, function($post_id, $post) {
if (defined(‘DOING_AUTOSAVE’) && DOING_AUTOSAVE) return;
$value = get_post_meta($post_id, ‘high_freq_key’, true);
global $wpdb;
// メタデータの更新を専用テーブルに同期
$wpdb->replace(
$wpdb->prefix . ‘custom_meta_store’,
[‘post_id’ => $post_id, ‘meta_value’ => $value],
[‘%d’, ‘%s’]
);
}, 10, 2);
パターンB：クエリの絞り込みを最適化する
もし既存の `wp_postmeta` を使い続けるなら、`meta_query` で `post_id` を先に特定し、その後にメタを取得する「2段階フェーズ」を強制するべきだ。
// 非効率なクエリの代表例を避けるための設計
$args = [
‘post_type’ => ‘product’,
‘meta_query’ => [
[
‘key’ => ‘category_code’,
‘value’ => ‘A-100’,
‘compare’ => ‘=’
]
],
// 重要なのは ‘post_id’ を特定する際にインデックスを効かせること
‘fields’ => ‘ids’,
];
$query = new WP_Query($args);
—
4. テクニカルリードからの提言：設計の美学
1. メタキーの命名規則を厳格化せよ: プレフィックス（例: `_`）を適切に使い、`is_protected` なメタデータと検索対象のメタデータを明確に分離せよ。
2. インデックスは魔法ではない: `meta_value` は `LONGTEXT` 型であり、ここに対するインデックスは、先頭N文字（Prefix Index）に制限される。`meta_value` を検索条件にするのは、可能な限り避けるか、`meta_value` を `BIGINT` 型等の固定長にキャストできる別テーブルへ逃がせ。
3. Object Cacheを信じろ: 何度も同じメタを叩くなら、`wp_cache_set` でメモリに乗せよ。データベースへのクエリは、0回に近づけるのが最高のパフォーマンスだ。
最後に
WordPressは「魔法の箱」ではない。内部構造を理解し、MySQLがどう動き、OSがどうI/Oを処理するかを想像できるエンジニアだけが、このシステムを掌握できる。
「動いた」で満足するな。`EXPLAIN`の結果が `type: ref` または `const` になるまで、コードを研ぎ澄ませ。それがプロフェッショナルの仕事だ。