WP_Queryの闇：`orderby`が引き起こす「Using filesort」の機械的真実とインデックス最適化の極意
WordPressのアーキテクチャにおいて、`WP_Query`は最も強力でありながら、最も誤用されやすいブラックボックスだ。特に、何気なく記述する `orderby` パラメータが、MySQLのストレージエンジン層でどのような絶望的なコストを生んでいるかを知るエンジニアは少ない。
今回は、`post_date` 以外のフィールド、例えば `meta_value` や `title` でソートを指定した瞬間に何が起きるのか。コンパイラ、ストレージエンジン、そしてランタイムの挙動に至るまで、低レイヤの視点からそのメカニズムを完全解剖する。
—
1. なぜ `post_date` 以外へのソートは「遅い」のか
データベースのインデックス（B-Tree構造）の根本原理を思い出してほしい。
WordPressの `wp_posts` テーブルにおいて、プライマリキーである `ID` や、デフォルトのソート対象である `post_date` は、あらかじめソートされた状態でB-Treeインデックスに保持されている。
しかし、`meta_key` を指定したカスタムフィールド値でのソートや、`post_title` でのソートを要求された瞬間、MySQLのオプティマイザ（クエリプランナ）の挙動は一変する。
`EXPLAIN` が示す `Using filesort` の悪夢
以下の典型的な `WP_Query` を発行したとする。
$query = new WP_Query( [
‘post_type’ => ‘product’,
‘posts_per_page’ => 10,
‘meta_key’ => ‘_price’,
‘orderby’ => ‘meta_value_num’,
‘order’ => ‘ASC’,
] );
このとき、MySQL内部で実行されているSQLの実行計画（`EXPLAIN`）を覗いてみよう。
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
|—|—|—|—|—|—|—|—|—|—|
| 1 | SIMPLE | wp_posts | ref | … | … | … | … | 50000 | Using where; Using filesort |
この `Using filesort` という文字列こそが、パフォーマンス低下の元凶である。
—
2. MySQLストレージエンジン（InnoDB）内部の挙動
`Using filesort` が表示された場合、MySQLはインデックス経由でデータを効率的に取り出すことができない。内部では以下の機械的プロセスが実行される。
1. フルスキャンまたは広範囲のインデックススキャン:
条件に一致するレコードをストレージからメモリ（InnoDB Buffer Pool）へ読み込む。
2. ソートバッファ（Sort Buffer）へのロード:
抽出した行のポインタ（あるいはソートキーと行ID）を、メモリ上の `sort_buffer_size` で割り当てられた領域に詰め込む。
3. クイックソート / マージソートの実行:
もしデータ量が `sort_buffer_size` を超えた場合、MySQLは一時ファイルをディスク（OSのテンポラリ領域またはInnoDBの臨時テーブルスペース）に作成し、マルチパス・マージソートを実行する。このディスクI/Oの発生が、レイテンシを跳ね上げる最大の要因だ。
4. ランダムアクセスによるオーバーヘッド:
ソートが完了した後、最終的な結果セットを構築するために、ソートされた順序に従って再度ストレージへランダムアクセス（Random I/O）を行い、実データを取得する。
CPUキャッシュのヒット率は激減し、ディスクシーク（またはOSページキャッシュのミス）が発生する。これが「`orderby` を変えただけでサイトが重くなった」の正体である。
—
3. WordPressコアの内部構造におけるジレンマ
WordPressのコア設計は、汎用性を極限まで高めている代償として、特定のクエリ最適化に対して脆弱である。
`WP_Query` は、渡されたパラメータを元にSQLを動的に構築する。`meta_key` を指定したソートでは、JOIN句に `wp_postmeta` が挟まる。
SELECT wp_posts.
FROM wp_posts
INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
WHERE wp_posts.post_type = ‘product’
AND wp_posts.post_status = ‘publish’
AND wp_postmeta.meta_key = ‘_price’
ORDER BY wp_postmeta.meta_value+0 ASC
LIMIT 0, 10
ここで `ORDER BY wp_postmeta.meta_value+0` と型変換（数値キャスト）が行われている点に注目してほしい。
MySQLは `meta_value`（VARCHAR型）に算術演算子 `+0` を適用しているため、カラムに対して関数や式が適用された状態（Expression）となり、既存のインデックスが完全に無効化される。B-Treeは使えず、問答無用でファイルソートの実行が確定する。
—
4. 限界を突破する：インデックスチューニングとクエリ設計の実装
このシステム的なボトルネックを回避し、大規模データ（数百万件の投稿とメタデータ）環境下でもミリ秒単位で応答させるためのアプローチを提示する。
対策A: 複合インデックスの物理的追加（DB層の最適化）
もし特定のメタキー（例: `_price`）で頻繁にソートを行うなら、MySQL側でカスタムインデックスを定義し、オプティマイザにインデックススキャンとソートのバイパスを強制させる必要がある。
— wp_postmeta に対して、meta_key と meta_value の構造化インデックスを付与
CREATE INDEX idx_meta_key_val_num ON wp_postmeta (meta_key(50), meta_value+0);
(注: MySQL 8.0以降であれば、Functional Indexes（関数インデックス）を使用するのが最もエレガントである)
ALTER TABLE wp_postmeta ADD INDEX idx_func_price ((CAST(meta_value AS SIGNED)));
対策B: アプリケーション層（WordPress）での非正規化とカスタムカラム
シニアエンジニアとして最も推奨するアプローチは、`wp_postmeta` への依存を断ち切ることだ。
頻繁にソートやフィルタリングを行うデータは、`wp_posts` テーブル自体の専用カラム（例: `post_content_filtered` の流用、あるいはカスタムテーブルの作成、あるいは `wp_posts` への物理カラム追加）に非正規化して保持するべきだ。
以下は、投稿保存時にメタデータを `wp_posts` のカスタム数値カラム（仮に `menu_order` や独自追加カラムとする）へ同期させ、`post_date` と同等のインデックス効率でソートさせる実装パターンである。
/
- パフォーマンス最適化：価格メタデータを専用カラムへ同期し、filesortを回避する
/
class HighPerformance_Sort_Optimizer {
public static function init() {
add_action( ‘save_post_product’, [ __CLASS__, ‘sync_price_to_column’ ], 10, 3 );
}
public static function sync_price_to_column( $post_id, $post, $update ) {
// 自動保存やリビジョン時はスキップ
if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
return;
}
// セキュリティ権限チェック等は省略（実際のプロダクションでは必須）
$price = get_post_meta( $post_id, ‘_price’, true );
if ( $price !== ” ) {
global $wpdb;
// wp_posts の未使用カラム（例: comment_count や独自カラム）に数値を格納し、
// そのカラムにインデックスを貼ることで filesort を完全に排除する
$wpdb.update(
$wpdb.posts,
[ ‘comment_count’ => absint( $price ) ], // ここでは例として comment_count を流用
[ ‘ID’ => $post_id ],
[ ‘%d’ ],
[ ‘%d’ ]
);
// オブジェクトキャッシュのクリア
clean_post_cache( $post_id );
}
}
}
HighPerformance_Sort_Optimizer::init();
この設計であれば、`WP_Query` の発行時に以下のような記述が可能になる。
$optimized_query = new WP_Query( [
‘post_type’ => ‘product’,
‘posts_per_page’ => 10,
‘orderby’ => ‘comment_count’, // インデックスが効くカラムでソート
‘order’ => ‘ASC’,
] );
これにより、`wp_postmeta` との `JOIN` が消滅し、`wp_posts` 単体のインデックススキャンだけでクエリが完結する。ストレージエンジンのバッファヒット率は劇的に向上し、CPUのコンテキストスイッチも最小限に抑え込まれる。
—
結び
WordPressのパフォーマンスチューニングとは、突き詰めれば「MySQLのオプティマイザがいかに快適にインデックスを利用できる状態を維持するか」という極めてプリミティブな戦いである。
「なんとなく動くコード」を書く時代は終わった。
背後で走るSQLのパケット、バッファプールの挙動、そしてインデックスのB-Tree構造を脳内で完璧にシミュレートし、システムに余計な負荷を1バイトたりとも与えないコードベースを構築することこそが、真のエンジニアリングである。