破綻するEAVモデル：`wp_postmeta`のインデックス戦略とクエリ実行計画の深淵
WordPressのデータベース設計は、柔軟性の代償として「EAV（Entity-Attribute-Value）モデル」というパンドラの箱を抱えている。特に`wp_postmeta`テーブルは、スケーラビリティの観点からは悪夢そのものだ。
シニアエンジニアであれば、`meta_key`のカーディナリティ（値の重複の少なさ）が、MySQLのオプティマイザをいかに欺き、クエリ実行計画を崩壊させるかを理解しているはずだ。今回は、この「見えないボトルネック」を解剖し、我々がどのようにしてWordPressのメタデータ層を掌握すべきかを論じる。
—
1. 物理構造の脆弱性：なぜインデックスは「裏切る」のか
`wp_postmeta`のインデックスは、複合インデックス `(post_id, meta_key)` で構成されている。しかし、ここには重大な設計上の制約がある。
- カーディナリティの逆転: `meta_key`の種類が極端に多い場合、あるいは逆に「特定のキー」に全レコードの90%が集中している場合、MySQLのオプティマイザはインデックスを無視し、フルテーブルスキャン（またはインデックススキャン）を選択する。
- データ型とバイナリ比較: `meta_key`は`VARCHAR(255)`であり、照合順序（Collation）に依存する。インデックスのカーディナリティ統計が古い場合、オプティマイザは「このインデックスを使っても絞り込み効率は悪い」と判断し、メモリ上のコストモデルを誤算する。
結果として、`get_posts()`や`WP_Query`が実行される際、内部では`JOIN`のネストが発生し、実行計画において`filesort`が発動する。これこそが、高負荷時にCPUスパイクを引き起こす最大の要因だ。
—
2. 実行計画の最適化：エンジニアリングの解
この問題を解決するには、WordPressの標準的なAPIに依存しつつも、クエリの実行経路を物理的に制御する必要がある。
A. 複合インデックスの再定義
もし特定の`meta_key`が頻繁にクエリ条件に使われるならば、デフォルトのインデックスだけでは不十分だ。以下のSQLで、特定キーを優先したカバリングインデックスを検討せよ。
— 特定のmeta_keyに対するカーディナリティを考慮した最適化
CREATE INDEX idx_meta_key_value ON wp_postmeta (meta_key, meta_value(20));
注意：`meta_value`は`LONGTEXT`であるため、先頭20文字程度をプレフィックスインデックスとして切るのが定石だ。
B. `meta_query`のメタデータ・キャッシングの回避
WordPressは`WP_Query`実行時に`update_meta_cache`を自動的に行うが、これが大規模なデータセットではメモリを大量消費し、GC（ガベージコレクション）を阻害する。
// パフォーマンス重視の極限クエリ
$args = [
‘post_type’ => ‘product’,
‘meta_query’ => [
[
‘key’ => ‘high_cardinality_key’,
‘value’ => ‘target_value’,
‘compare’ => ‘=’
]
],
‘update_post_meta_cache’ => false, // メモリ消費とGC負荷を抑制
‘update_post_term_cache’ => false,
];
$query = new WP_Query($args);
—
3. 高度な戦略：カスタムテーブルへの脱却
もし君が管理するサイトの`wp_postmeta`が数千万行を超えているなら、WordPressの標準的なメタデータAPIは「技術的負債」以外の何物でもない。以下のアーキテクチャへの移行を強く推奨する。
1. 分離: 頻繁に検索・ソートされるメタデータは、`wp_postmeta`から切り出し、専用のカスタムテーブル（例: `wp_product_attributes`）へ移す。
2. 型定義: `wp_postmeta`の`meta_value`は常に文字列として扱われる。カスタムテーブルを作成すれば、`INT`や`DECIMAL`型を使用でき、インデックス効率が劇的に向上する。
3. ORMによる抽象化: `$wpdb`を使って直接SQLを叩くのではなく、モデル層を作成し、WordPressのクエリ実行順序（`posts_clauses`フック）をフックして、クエリをカスタムテーブルへリダイレクトさせる。
add_filter(‘posts_clauses’, function($clauses, $wp_query) {
global $wpdb;
// 特定のカスタム条件時に、JOIN対象をwp_postmetaからカスタムテーブルへ差し替える
if ($wp_query->get(‘use_custom_meta_table’)) {
$clauses[‘join’] .= ” INNER JOIN {$wpdb->prefix}custom_meta_table AS cmt ON {$wpdb->posts}.ID = cmt.post_id”;
// ここで既存のmeta_queryによるJOINを解除する処理を追加
}
return $clauses;
}, 10, 2);
—
結論：アーキテクトとしての矜持
WordPressの内部コアは、汎用性を極めたがゆえに、特定の高負荷環境において破綻する構造を持っている。我々シニアエンジニアの仕事は、その「汎用性の皮」を剥ぎ取り、背後にあるストレージエンジンとカーネルの対話に介入することだ。
`wp_postmeta`のカーディナリティを疑え。インデックスの統計情報を監視せよ。そして何より、WordPressというフレームワークの「中」ではなく、その「下」で何が起きているかを常に可視化し続けろ。
限界を突破した先にしか、真のパフォーマンスは存在しない。