コードレビューの席で、次のようなコードを見かけたとしよう。
// レビュー対象コード：絶対に本番環境へ入れてはならないアンチパターン
$args = array(
‘post_type’ => ‘property’,
‘posts_per_page’ => 20,
‘meta_key’ => ‘property_price’,
‘orderby’ => ‘meta_value_num’,
‘order’ => ‘DESC’,
);
$query = new WP_Query( $args );
「不動産価格の降順で上位20件を取得する」――要件としては極めて一般的だ。しかし、このクエリが数百万件規模のプロダクション環境を静かに、そして確実に死に至らしめる原因になることを、どれだけのエンジニアが理解しているだろうか。
今回は、`WP_Query` におけるカスタムフィールド（メタ値）ソートの内部挙動を解剖し、なぜこれがパフォーマンスの劇薬となるのか、そしてデータベースの物理層からどう美しく解決すべきか、テクニカルリードの視点からロジカルに解説する。
—
なぜ `meta_value` / `meta_value_num` のソートは重いのか？
WordPressのコアデータベース設計（EAVモデルを採用した `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)
);
1. インデックスの効かない複合条件と全表スキャン
`WP_Query` で `meta_key` と `orderby => ‘meta_value_num’` を指定したとき、MySQL（InnoDB）内部で何が起きているか。発行されるSQLの大枠はこうだ。
SELECT SQL_CALC_FOUND_ROWS wp_posts.
FROM wp_posts
INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
WHERE wp_posts.post_type = ‘property’
AND wp_posts.post_status = ‘publish’
AND wp_postmeta.meta_key = ‘property_price’
ORDER BY CAST(wp_postmeta.meta_value AS SIGNED) DESC
LIMIT 0, 20;
ここに致命的な問題が3つある。
- `meta_value` は `longtext` 型である： 任意長の文字列を格納するため、インデックスのプレフィックス長制限に引っかかりやすく、数値としてのソートには必ず型変換（`CAST` や `CONVERT`）が走る。
- 一時テーブル（Temporary Tables）とFilesortの発生： `ORDER BY` 句で関数やキャストを使用するため、MySQLはインデックスを利用した高速な順序制御ができず、ディスク上（あるいはメモリ上）に一時テーブルを作成し、大規模な `Filesort` を実行する。
- `SQL_CALC_FOUND_ROWS` の呪い： WordPressはデフォルトで全ヒット数を計算するため、条件に合致する全レコードのメタ値を評価させられる。
データ件数が10万件を超えたあたりから、このクエリはCPUを100%に張り付かせ、データベースのコネクションプールを枯渇させる。
—
対策：ソート専用カラム（専用プリミティブ型カラム）の導入
この問題に対する唯一にして最大の王道アプローチは、「ソートやフィルタリングで頻繁に使用するメタ値は、専用のカスタムカラムとして `wp_posts` テーブル自体、またはカスタムテーブルへ同期・分離する」ことだ。
今回は、パフォーマンスと保守性のバランスが最も良い「`wp_posts` テーブルへのカラム追加（またはWordPress標準のカスタムテーブル拡張）」を前提に、堅牢な設計パターンをコードで示そう。
設計方針
1. `property_price` が更新（保存）されたタイミングで、物理カラム（例: `post_price` または `wp_posts` の拡張、もしくは専用メタテーブルのインデックス付きカラム）に数値を同期する。
2. `WP_Query` のフック（`posts_clauses`）を使い、結合とソートの対象をメタテーブルから軽量なインデックス付きカラムへすげ替える。
—
実装：プロダクションコード例
以下のコードは、カスタム投稿タイプ `property` の価格ソートを最適化するための完全なコンポーネント設計である。
/
if ( ! defined( ‘ABSPATH’ ) ) {
exit;
}
class Property_Query_Optimizer {
public function __construct() {
// 1. 値の保存時に専用カラム（または別領域）へ非正規化して同期するフック
add_action( ‘save_post_property’, array( $this, ‘sync_property_price_column’ ), 10, 3 );
// 2. WP_Query の SQL 生成段階でカスタムソートロジックを差し込む
add_filter( ‘posts_clauses’, array( $this, ‘optimize_price_orderby_clause’ ), 10, 2 );
}
/
- 【同期処理】メタ値の更新をトリガーに、高速検索用の別領域（今回は例としてTransient/別メタ構造、
- または実務では wp_posts のカスタムカラムや専用テーブルを想定）へ値をプリコンパイルする。
/
public function sync_property_price_column( $post_id, $post, $update ) {
// 自動保存やリビジョン、権限チェック
if ( defined( ‘DOING_AUTOSAVE’ ) && DOING_AUTOSAVE ) return;
if ( wp_is_post_revision( $post_id ) ) return;
$price = get_post_meta( $post_id, ‘property_price’, true );
// 実務ではここで $wpdb を使って専用の高速カラム（例: wp_posts.menu_orderを流用するか、カスタムカラム）へ数値として保存する。
// 例：update_post_meta($post_id, ‘_optimized_price_int’, intval($price));
// ※ wp_postmeta 内であっても、メタキーを絞った専用の複合インデックスがあれば改善しますが、
// 真のスケールを目指すならプリミティブ型カラムへの保存がベストです。
}
/
- 【クエリ最適化】orderby => ‘optimized_price’ が指定された場合、結合とソートを書き換える
/
public function optimize_price_orderby_clause( $clauses, $query ) {
global $wpdb;
// 特定のクエリ条件でのみ発動させる（安全性の担保）
if ( ‘optimized_price’ !== $query->get( ‘orderby’ ) ) {
return $clauses;
}
$order = strtoupper( $query->get( ‘order’ ) );
$order = ( ‘ASC’ === $order ) ? ‘ASC’ : ‘DESC’;
// JOIN句の追加（もし専用の高速メタテーブルや別カラム結合を行う場合）
// ここではコアの wp_postmeta を使うが悪夢のフルスキャンを防ぐため、
// あらかじめインデックスが効くサブクエリや別名テーブル結合に最適化する例を示す。
$alias = ‘p_price_opt’;
$clauses[‘join’] .= ” LEFT JOIN {$wpdb->postmeta} AS {$alias} ON ({$wpdb->posts}.ID = {$alias}.post_id AND {$alias}.meta_key = ‘property_price’)”;
// ORDER BY 句の置き換え（CASTを安全かつ効率的な型に限定）
$clauses[‘orderby’] = “CAST({$alias}.meta_value AS UNSIGNED) {$order}”;
// 注意: これだけでは完全なインデックスヒットはしないため、
// 本格的なスケールでは wp_postmeta の (meta_key, meta_value(20)) などの部分インデックス、
// もしくは専用カスタムテーブルへの移行が必須となる。
return $clauses;
}
}
new Property_Query_Optimizer();
—
さらに踏み込む：DB物理層でのインデックスチューニング
もし構造上、どうしても `wp_postmeta` をそのまま使用せざるを得ないレガシー制約がある場合、MySQLのインデックス設計で無理やり性能を引き上げるアプローチも存在する。
InnoDBにおいて、`longtext` 型のカラムにはプレフィックスインデックス（長さを指定したインデックス）しか貼れない。
— wp_postmeta の meta_key と meta_value の先頭部分に対する複合インデックスの作成
— （※データベース管理者権限での実行が必要）
ALTER TABLE wp_postmeta ADD INDEX idx_meta_key_val_prefix (meta_key(50), meta_value(20));
このインデックスが存在する場合、オプティマイザは `meta_key = ‘property_price’` の絞り込みにおいてインデックスを利用できるようになり、フルテーブルスキャンを回避できる確率が劇的に跳ね上がる。ただし、これもあくまで「対症療法」であり、データの肥大化に伴いいずれ限界が来ることを忘れてはならない。
—
テクニカルリードからの総括
WordPressの柔軟性は最大の武器であるが、それは「何も考えずに書いたコードがそのまま動く」という甘えを生む温床でもある。
1. 安易な `meta_value` ソートはデータベースの殺人クエリであると認識せよ。
2. 要件定義の段階で、ソート対象となるデータはプリミティブ型（数値・日付）の専用カラム、または適切にインデックス設計された専用テーブルに切り出すアーキテクチャをファーストチョイスとせよ。
3. コードレビューでは、単に「動くか」ではなく「100万件のデータが入ったときに何番目のクエリでスローダウンするか」を常に想像させよ。
システムの寿命を決めるのは、フレームワークの便利機能ではなく、エンジニアのデータベースに対するリスペクトと構造化の技量である。あなたの書く次のクエリが、インデックスに愛される美しいものであることを期待する。