WP_Queryの内部解剖：`SAVEQUERIES`によるSQL可視化とクエリ最適化の極限
WordPressのコアシステムにおいて、`WP_Query`は単なるデータ取得ラッパーではない。それはURLのパースから始まり、条件分岐の解決、SQLの動的構築、そしてグローバルなデータベース抽象化レイヤーである`wpdb`を介したMySQL/MariaDBへのクエリ発行に至るまでの、複雑なライフサイクルの中枢である。
多くの開発者は、遅延の原因を「サーバーのスペック不足」や「PHPのバージョン」に求めがちだが、真のボトルネックは常にデータベース層、とりわけ非効率な`WP_Query`の構築方法と、それに伴うインデックスの欠落にある。
本稿では、`SAVEQUERIES`定数を用いたSQLの可視化という最初のステップから、MySQLの実行計画（EXPLAIN）を見据えたクエリの最適化まで、システムの内部メカニズムを紐解いていく。
—
1. `SAVEQUERIES` の内部動作とメモリ管理のトレードオフ
WordPressのデバッグにおいて、発行されたSQLを追跡する最もプリミティブかつ確実な方法は、`wp-config.php`に以下の定数を定義することだ。
define( ‘SAVEQUERIES’, true );
内部で何が起きているのか？
この定数を有効化すると、`wpdb`クラス（`wp-includes/class-wpdb.php`）のクエリ実行メソッド内において、実行されたすべてのSQL文、実行時間、そしてそのクエリがコールされた時点のPHPのバックトレース（コールスタック）が、グローバル変数 `$wpdb->queries` に配列として蓄積される。
実際のコアコードの挙動を模した概念を見てみよう。
// wp-includes/class-wpdb.php の内部挙動の概念
if ( SAVEQUERIES ) {
$this->queries[] = array(
$query,
$this->timer_stop(),
$this->get_caller(), // debug_backtrace() のラッパー
$this->timer_start_time,
// …
);
}
この処理は非常に強力だが、同時に重大なパフォーマンス上のペナルティを伴う。すべてのクエリ文字列と膨大なデバッグトレース（配列とオブジェクトの入れ子構造）がPHPのメモリヒープ上に保持されるため、リクエストあたりのメモリ消費量が急増し、場合によっては `out of memory` エラーを引き起こす。
> アーキテクトの知見:
> `SAVEQUERIES`は、本番環境（Production）で常時有効化してはならない。必ずローカル環境（Local/Staging）かつ、特定のプロファイリングセッションに限定して使用すべきである。
—
2. 実践：ボトルネッククエリのキャプチャと可視化
`SAVEQUERIES`によって蓄積されたデータは、フッターや管理者バー、あるいは特定のデバッグ用フックを通じて出力・解析できる。以下は、閾値（例: 0.01秒以上）を超える「重いクエリ」を検出し、スタックトレースと共にログへ出力する実用的なコードだ。
/
- 実行時間が長いクエリを検出し、エラーログに出力するスニペット
- wp-content/mu-plugins/ またはテーマのfunctions.phpに配置
/
add_action( ‘wp_footer’, function() {
if ( ! defined( ‘SAVEQUERIES’ ) || ! SAVEQUERIES ) {
return;
}
global $wpdb;
if ( empty( $wpdb->queries ) ) {
return;
}
$threshold = 0.01; // 10ms以上のクエリを対象とする
$heavy_queries = [];
foreach ( $wpdb->queries as $q ) {
list( $sql, $duration, $caller ) = $q;
if ( $duration > $threshold ) {
$heavy_queries[] = [
‘sql’ => $sql,
‘duration’ => round( $duration 1000, 2 ) . ‘ms’,
‘caller’ => $caller,
];
}
}
if ( ! empty( $heavy_queries ) ) {
error_log( ‘— WP_Query Performance Warning —‘ );
foreach ( $heavy_queries as $hq ) {
error_log( sprintf( “Duration: %s | SQL: %s | Called by: %s”, $hq[‘duration’], $hq[‘sql’], $hq[‘caller’] ) );
}
}
}, PHP_INT_MAX );
このコードにより、どのPHPの関数（どのプラグイン、どのテーマのテンプレート）が、どのようなSQLを発行してボトルネックになっているのかを正確に特定できる。
—
3. `WP_Query` が生成する「悪魔のSQL」の構造分析
プロファイリングによって特定された重いクエリの多くは、`WP_Query` のデフォルトの挙動に起因する。特に以下のようなパラメータの組み合わせは、データベースのフルスキャンを誘発しやすい。
危険なパターン例
$args = array(
‘post_type’ => ‘post’,
‘posts_per_page’ => 10,
‘meta_key’ => ‘view_count’,
‘orderby’ => ‘meta_value_num’,
‘s’ => ‘WordPress’,
);
$query = new WP_Query( $args );
このコードが発行するSQLを想像してほしい。
1. `s` パラメータにより、`wp_posts.post_title`, `wp_posts.post_content` に対する `LIKE` 検索（前方一致・後方一致）が走る。これはインデックスを完全に破壊する（`%keyword%` のため）。
2. `meta_key` と `meta_value_num` により、`wp_postmeta` テーブルとの `JOIN` が発生する。
3. `wp_postmeta` はデフォルトの状態ではメタキー（`meta_key`）に対してプレフィックスインデックスはあるものの、大規模なデータセットでは Filesort（ファイルソート）が発生し、MySQLのCPU使用率が跳ね上がる。
—
4. インデックスチューニングとクエリ最適化の極意
SQLのログ出力によって「どのクエリが遅いか」が判明した次に行うべきは、MySQLのオプティマイザへのアプローチだ。
1. `no_found_rows` によるページネーションの最適化
`WP_Query` はデフォルトで、ページネーション（`paged`）の計算のために `SQL_CALC_FOUND_ROWS` を含んだクエリを発行し、その後 `SELECT FOUND_ROWS()` を実行する。これにより、MySQLは LIMIT句を無視してマッチするすべての行をスキャンする。
もし総件数（max_num_pages）が不要なクエリであれば、必ず以下のパラメータを指定せよ。
$args = array(
‘post_type’ => ‘my_custom_type’,
‘no_found_rows’ => true, // FOUND_ROWS() の計算をスキップし、クエリを高速化
);
2. メタデータのキャッシュと複合インデックス
カスタムフィールド（Post Meta）を用いたソートやフィルタリング多用する場合は、データベース側でのインデックス追加が不可欠である。デフォルトの `wp_postmeta` テーブルには `meta_key` と `post_id` のユニークキーはあるが、値（`meta_value`）を含んだ検索や数値変換ソートには最適化されていない。
必要に応じて、以下のような複合インデックスを検討する。
— meta_key と meta_value を頻繁に検索・ソートする場合のインデックス設計例
ALTER TABLE wp_postmeta ADD INDEX meta_key_value_idx (meta_key(191), meta_value(191));
(※ InnoDBのインデックス長制限とutf8mb4を考慮したプレフィックス長の設定)
—
結言：システムを掌握するということ
`SAVEQUERIES`を用いたSQLの可視化は、WordPressのブラックボックス化されたデータ層をハックするための最初にして最重要なステップに過ぎない。
真にスケーラブルなWordPressアーキテクチャを構築するためには、PHPコードレベルでの最適化に留まらず、MySQLの実行計画（EXPLAIN）を読み解き、インデックスのカーディナリティを考慮したデータベース設計を行う必要がある。
フレームワークの便利さに依存するのではなく、その下で稼働するランタイム、データベース、そしてネットワークの挙動のすべてを脳内でトレースできる者だけが、真に高負荷に耐えうる極限のシステムを掌握できるのだ。