WordPressを掌握する極限の知見：WP_Queryの実行計画（EXPLAIN）を自動監視するカスタムプロファイラーの構築
大規模なWordPressアプリケーションにおいて、`WP_Query` は最も強力であり、同時に最も誤用されやすいブラックボックスである。ひとたびメタキーの多重クエリ（`meta_query`）や複雑なタクソノミー条件、そして悪名高き `no_found_rows = false` による無駄な `SQL_CALC_FOUND_ROWS`（MySQL 8.0以前、あるいは非効率なページネーションカウント）が組み合わさると、データベースのCPU使用率は天井を突き抜ける。
多くのエンジニアは、スロークエリログや Query Monitor プラグインに頼りがちだが、真のプロダクション環境において必要なのは、「本番のランタイムで静かに、しかし容赦なく遅延クエリを検出し、MySQLのオプティマイザが下した実行計画（EXPLAIN）と共に構造化ログとして吐き出す自律型のプロファイラー」である。
本稿では、WordPressのデータベース抽象化レイヤ（`wpdb`）の最深部にフックし、`WP_Query` が発行する生のSQL文をインターセプト、動的に `EXPLAIN` を実行してボトルネックを自動検知するプロファイラーの実装を解説する。
—
1. `WP_Query` と `wpdb` のライフサイクル：どこでクエリを捕捉すべきか
WordPressのクエリ生成から実行までのフローを低レイヤで確認する。
1. `WP_Query->get_posts()` が条件を解析し、SQL文字列を組み立てる。
2. `$wpdb->query()` または `$wpdb->get_results()` にSQLが渡される。
3. MySQLサーバーがパースし、コストベースオプティマイザ（CBO）が実行計画（Execution Plan）を生成・実行する。
ここで重要なのは、`posts_request` フィルターフックでSQL文字列を取得できる点だ。しかし、単にSQLを取得するだけでは不十分である。そのSQLがインデックスをフル活用しているか（Type: `ALL` や `index` になっていないか）を検証するためには、実行時に `EXPLAIN` クエリを同一セッション内で走らせる必要がある。
しかし、すべてのクエリに対して `EXPLAIN` を同期実行することは、それ自体がオーバーヘッドとなり本番環境では毒となる。そのため、実行時間が一定の閾値（例: 50ms）を超えたクエリ、または特定の危険なシグネチャを持つクエリのみを非同期にプロファイリングする機構が求められる。
—
2. カスタムプロファイラーのアーキテクチャ設計
以下の要件を満たすクラス `WP_Query_Profiler` を構築する。
- インターセプト: `posts_request` フィルターで発行されるSQLを捕捉し、マイクロ秒単位のタイマーを起動。
- 閾値判定: 実行時間が `THRESHOLD_MS` を超えた場合、または `EXPLAIN` の結果、`type = ALL`（フルテーブルスキャン）が検出された場合にログ対象とする。
- EXPLAIN解析: 該当SQLの先頭に `EXPLAIN` を付与して再実行し、MySQLのオプティマイザがどのようにインデックスを選定したかをJSONとしてキャプチャする。
- コンテキストの保持: どのプラグイン、どのテーマのどのテンプレート階層からそのクエリが発行されたのか（バックトレース）を記録する。
—
3. 実装コード：`WP_Query_Profiler`
以下のコードをMust-Useプラグイン（`mu-plugins`）として配置し、完全なサイレント監視体制を構築する。
/
if ( ! defined( ‘ABSPATH’ ) ) {
exit;
}
class WP_Query_Profiler {
/
- 実行時間の閾値（ミリ秒）。これを超えたクエリを詳細プロファイル対象とする。
/
private const LATENCY_THRESHOLD_MS = 50.0;
/
- クエリ開始時間を保持する一時バッファ
/
private static array $timers = [];
public static function init(): void {
// SQL生成直後にフック（パラメータ置換前のプレースホルダー状態）
add_filter( ‘posts_request’, [ self::class, ‘capture_request’ ], 10, 2 );
// データベースクエリ完了後にフック
add_filter( ‘query’, [ self::class, ‘profile_query’ ], 10, 1 );
}
/
- クエリの開始時間を計測するためのプレパレーション
/
public static function capture_request( string $sql, \WP_Query $query ): string {
// wpdbの内部プロパティを利用してクエリのユニークなハッシュを生成
$sql_hash = md5( $sql );
self::$timers[ $sql_hash ] = [
‘start’ => microtime( true ),
‘sql’ => $sql,
‘queried’ => $query,
];
return $sql;
}
/
- クエリ実行後のインターセプトとEXPLAIN解析
/
public static function profile_query( string $sql ): string {
$sql_hash = md5( $sql );
if ( ! isset( self::$timers[ $sql_hash ] ) ) {
return $sql;
}
$elapsed_ms = ( microtime( true ) – self::$timers[ $sql_hash ][‘start’] ) 1000;
$query_data = self::$timers[ $sql_hash ];
unset( self::$timers[ $sql_hash ] );
// 閾値を超えた、または特定の危険なパターン（全表スキャン等）の予兆がある場合
if ( $elapsed_ms >= self::$LATENCY_THRESHOLD_MS ) {
self::execute_explain_and_log( $sql, $elapsed_ms, $query_data[‘queried’] );
}
return $sql;
}
/
- EXPLAINを実行し、オプティマイザの判断を構造化してログに記録
/
private static function execute_explain_and_log( string $sql, float $elapsed_ms, \WP_Query $query ): void {
global $wpdb;
// プリペアドステートメントのプレースホルダー（%sなど）を安全に処理できない場合があるため、
// EXPLAINはSELECT文に対してのみ実行
if ( stripos( trim( $sql ), ‘SELECT’ ) !== 0 ) {
return;
}
$explain_sql = “EXPLAIN FORMAT=JSON ” . $sql;
$explain_result = $wpdb->get_row( $explain_sql, ARRAY_A );
if ( ! $explain_result || ! isset( $explain_result[‘EXPLAIN’] ) ) {
return;
}
$explain_json = json_decode( $explain_result[‘EXPLAIN’], true );
// フルテーブルスキャン（type: ALL）の検出など、クリティカルな指標をチェック
$is_full_scan = self::detect_full_table_scan( $explain_json );
$log_payload = [
‘timestamp’ => gmdate( ‘Y-m-d H:i:s’ ),
‘elapsed_ms’ => round( $elapsed_ms, 2 ),
‘full_scan’ => $is_full_scan,
‘sql’ => $sql,
‘explain_plan’ => $explain_json,
‘query_vars’ => $query->query_vars,
‘backtrace’ => self::get_filtered_backtrace(),
];
// 本番環境では error_log または専用のログドライバー（Monolog等）へ非同期出力
error_log( ‘[WP_Query_Profiler] ‘ . wp_json_encode( $log_payload, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE ) );
}
/
- EXPLAINのJSONツリーからテーブルフルスキャンを再帰的に検出
/
private static function detect_full_table_scan( array $node ): bool {
if ( isset( $node[‘access_type’] ) && $node[‘access_type’] === ‘ALL’ ) {
return true;
}
foreach ( $node as $key => $value ) {
if ( is_array( $value ) && self::detect_full_table_scan( $value ) ) {
return true;
}
}
return false;
}
/
- どこからクエリが呼ばれたかを特定するためのコールスタックトレース
/
private static function get_filtered_backtrace(): array {
$trace = debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS, 10 );
$filtered = [];
foreach ( $trace as $frame ) {
if ( isset( $frame[‘file’] ) && strpos( $frame[‘file’], ABSPATH ) === 0 ) {
$filtered[] = [
‘file’ => str_replace( ABSPATH, ”, $frame[‘file’] ),
‘line’ => $frame[‘line’] ?? 0,
‘func’ => $frame[‘function’] ?? ”,
];
}
}
return $filtered;
}
}
// プロファイラーの起動
WP_Query_Profiler::init();
—
4. ログ解析とインデックスチューニングの実践
上記プロファイラーが記録する `EXPLAIN FORMAT=JSON` の出力を元に、データベースのインデックスを極限まで最適化するアプローチを解説する。
ケーススタディ：メタキーによるソートと複合条件の破綻
以下のような `WP_Query` が発行されたとする。
$query = new WP_Query([
‘post_type’ => ‘product’,
‘meta_query’ => [
‘relation’ => ‘AND’,
[
‘key’ => ‘_stock_status’,
‘value’ => ‘instock’,
],
[
‘key’ => ‘_price’,
‘type’ => ‘NUMERIC’,
‘compare’ => ‘<',
'value' => 1000,
],
],
‘orderby’ => ‘meta_value_num’,
‘meta_key’ => ‘_price’,
‘order’ => ‘DESC’,
]);
このクエリはデフォルトの状態では、`wp_postmeta` テーブルに対して悲惨なフルテーブルスキャンを引き起こす。プロファイラーが出力する `EXPLAIN` のJSONには、以下のような致命的な兆候が現れる。
{
“query_block”: {
“select_id”: 1,
“table”: {
“table_name”: “wp_postmeta”,
“access_type”: “ALL”,
“rows_examined_per_scan”: 450000,
“filtered”: 1.11,
“using_temporary”: true,
“using_filesort”: true
}
}
}
- `access_type: “ALL”`: インデックスが効いておらず、45万行のポストメタを全件走査している。
- `using_filesort: true`: メタ値のキャストとソートのために一時ファイルへのディスクI/Oが発生している。
対策：マルチカラム・インデックス（複合インデックス）の強制
WordPressコアの `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(191))
) ENGINE=InnoDB;
単一の `meta_key` インデックスでは、`meta_key` で絞り込んだ後に `meta_value`（数値としてソート）を効率的に引くことができない。プロファイラーが検知したこのボトルネックに対し、データベース層へ以下の複合インデックスを追加することで、`EXPLAIN` の結果を劇的に改善できる。
— meta_key と post_id, そして meta_value の先頭部分を網羅する複合インデックス
ALTER TABLE wp_postmeta ADD INDEX idx_meta_query_optimization (meta_key(100), meta_value(50), post_id);
このインデックス追加後、再度プロファイラー経由でクエリを走らせると、`access_type` は `ref` または `range` に改善され、`rows_examined_per_scan` は数百万行から数件へと激減する。
—
5. シニアエンジニアが知るべき運用上の注意点
1. プロダクション環境での `EXPLAIN` のコスト:
MySQL 8.0以降、`EXPLAIN` 自体のオーバーヘッドは極めて小さくなっているが、それでも高スループットな環境（1000req/sec以上）では、すべてのSELECT文に対するトレーシングはCPUキャッシュを汚染する。必ず上記のコードのように `LATENCY_THRESHOLD_MS` を設け、遅いクエリに限定してサンプリングすること。
2. ログのローテーションとストレージ肥大化:
`error_log` への書き込みはI/Oブロックを引き起こす可能性があるため、高負荷環境では Fluentd や Logstash などのサイドカープロセスへ非同期送信するカスタムレコーダーへ `error_log` 部分を差し替えるべきである。
3. `SQL_CALC_FOUND_ROWS` の完全排除:
もしプロファイラーのログで多くのクエリが `no_found_rows => false` で発行されているのを発見した場合は、即座に `no_found_rows => true` をデフォルト化する設計変更を行うこと。ページネーションの総件数算出（`SELECT FOUND_ROWS()`）は、InnoDBのバッファプールを無駄に消費する最大の元凶である。
システムの内部構造を直視し、感覚ではなく「データ」と「実行計画」に基づいてボトルネックを叩く。これこそが、限界を超えたWordPressスケーリングの唯一にして確実なアプローチである。