WordPressの「EAV地獄」を脱却せよ：カスタムフィールド検索を爆速化する専用フラットテーブル設計
WordPressの `wp_postmeta` は、EAV（Entity-Attribute-Value）モデルを採用した柔軟性の塊だ。しかし、その柔軟性は「大規模な検索」という文脈においては、パフォーマンス上の毒となる。
データ量が増え、`meta_key` と `meta_value` のペアが数百万行に達した時、`WP_Query` の `meta_query` を実行すれば、MySQLはテーブルフルスキャンに近い惨状に陥る。インデックスを貼ったところで、EAV構造特有の結合（JOIN）コストは逃れられない。
真にスケーラブルなWordPressサイトを構築するエンジニアは、「検索用のフラットテーブルを自前で定義し、同期させる」という設計パターンを採用する。今回は、その堅牢な実装戦略を伝授する。
—
1. なぜ「同期型フラットテーブル」なのか？
`wp_postmeta` へのクエリが遅い理由は明白だ。
1. 行指向の検索: 1つの投稿の属性が複数行に分かれているため、特定の条件で絞り込むには `JOIN` が必須となる。
2. 型キャストの不在: `meta_value` はロングテキスト型であるため、数値や日付として比較する際に暗黙の型変換が発生し、インデックスが無視される。
検索専用の `wp_custom_search_index` テーブルを用意し、投稿の保存時に必要なカラムだけをフラットに書き出すことで、`SELECT FROM wp_custom_search_index WHERE price < 1000 AND category = 'sale'` といった、単一テーブルへの高速なO(1)またはO(log n)クエリを実現する。
—
2. 実装パターン：堅牢な同期アーキテクチャ
単にデータをコピーするだけでは、データ不整合の温床になる。WordPressのフックシステムを活用し、アトミックな同期を保証する。
ステップ1: 検索用テーブルの定義
マイグレーション（または `dbDelta`）を使用してテーブルを作成する。
function create_search_index_table() {
global $wpdb;
$table_name = $wpdb->prefix . ‘custom_search_index’;
$charset_collate = $wpdb->get_charset_collate();
$sql = “CREATE TABLE $table_name (
post_id bigint(20) NOT NULL,
price decimal(10,2) DEFAULT ‘0.00’ NOT NULL,
stock_status tinyint(1) DEFAULT 1 NOT NULL,
updated_at datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (post_id),
KEY price_idx (price),
KEY stock_idx (stock_status)
) $charset_collate;”;
require_once(ABSPATH . ‘wp-admin/includes/upgrade.php’);
dbDelta($sql);
}
ステップ2: 保存イベントでの同期（Service層の分離）
`save_post` フックで直接処理を書くのは避け、同期ロジックをクラスにカプセル化する。
class SearchIndexManager {
public static function sync($post_id) {
// リビジョンや自動保存は無視
if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) return;
global $wpdb;
$table = $wpdb->prefix . ‘custom_search_index’;
// 必要なメタデータを取得
$price = get_post_meta($post_id, ‘_price’, true);
$stock = get_post_meta($post_id, ‘_stock_status’, true);
// upsertによるデータ整合性の維持
$wpdb->replace($table, [
‘post_id’ => $post_id,
‘price’ => (float)$price,
‘stock_status’ => (int)$stock,
‘updated_at’ => current_time(‘mysql’)
], [‘%d’, ‘%f’, ‘%d’, ‘%s’]);
}
}
// フック登録
add_action(‘save_post_product’, [‘SearchIndexManager’, ‘sync’]);
—
3. パフォーマンスを最大化する設計の極意
このアーキテクチャをプロダクションで運用する際の注意点がある。
1. 非同期化の検討:
同期処理が重い場合（外部API連携を含む場合など）、`save_post` で同期させるのはユーザー体験を損なう。Action Scheduler (WooCommerceにも同梱) や WP-Cron を使い、キューイングしてバックグラウンドで処理を行うのが正解だ。
2. 読み取りの分離:
検索結果を表示する際、`WP_Query` を使う必要はない。`$wpdb->get_results()` を使い、検索用テーブルから直接 `post_id` の配列を取得し、`get_posts()` に `post__in` で渡すのが最も効率的だ。
3. トランザクションと整合性:
大量のデータを一度に更新する場合、`$wpdb->query(‘START TRANSACTION’)` を検討せよ。WordPressのコアはトランザクションを明示的に制御できるため、整合性が最優先されるシステムでは必須だ。
—
最後に：なぜこれが「プロのコード」なのか
一般的なプラグイン開発者は、`meta_query` の書き方ばかりを追い求める。しかし、我々テクニカルリードが目指すべきは、「データベース負荷の可視化」と「クエリの予測可能性」だ。
WordPressの標準機能に依存しすぎず、かといってコアを壊さない。「必要な箇所だけを高速化する専用インフラを構築する」というこのアプローチは、将来的にElasticsearchなどの外部検索エンジンへ移行する際のブリッジとしても非常に有効な設計となる。
次は、このインデックスをどうやって効率的にパージし、キャッシュ戦略と組み合わせるか……その深淵についても、また機会があれば語ろう。コードは正直だ。設計の意図が、パフォーマンスという形で必ず返ってくる。