こんにちは！WordPressの裏側の仕組みや、データベースとの対話に興味を持ってこのページを開いてくれたんですね。素晴らしい探求心です！
他のプログラミング言語やフレームワークを経験した方なら、「ORM（オブジェクト関係マッピング）やクエリビルダーの裏で、実際どんなSQLが発行されているんだろう？」と気になったことがあるはずです。WordPressの世界では、それがお馴染みの `WP_Query` ですよね。
今回は、プログラミング初学者の方や、他言語からWordPressの世界に飛び込んできた方に向けて、「WP_Queryが裏でどんなSQLを叩いているのか、そしてどうやってそのパフォーマンスを監視・最適化するのか」を、優しく、かつ本質的な部分まで徹底的に解説していきますね。
ここをクリアすれば、あなたのWordPress開発スキルは間違いなく一皮むけますよ。一緒にマスターしていきましょう！
—
1. WP_Queryの裏側：なぜクエリの監視が必要なのか？
WordPressを手軽に使っていると忘れがちですが、`new WP_Query()` を実行するたび、内部ではMySQLデータベースに対して重たいSQLクエリが発行されています。
特に、`meta_query`（カスタムフィールドでの絞り込み）や `tax_query`（タクソノミーでの絞り込み）を複雑に組み合わせたり、`posts_per_page = -1` なんて指定をしてしまうと、データベースは悲鳴を上げます。
イメージ図で表すと、こんな感じです。
[ あなたのPHPコード ]
↓ ( new WP_Query() )
[ WP_Query 内部 ] —> SQLを組み立てる
↓
[ MySQL データベース ] —> フルテーブルスキャン（全件走査）が発生！ 😱
↓
[ ページの表示が激遅に… ]
データベースが「インデックス（索引）」を使えず、全件をしらみつぶしに探す状態（フルテーブルスキャン）になると、アクセスが増えた瞬間にサイトがダウンしてしまいます。
だからこそ、「今、どんなSQLが発行されていて、データベースがどう処理しているのか（実行計画）」を自動で監視する仕組みが必要なんです。
—
2. データベースの通信簿「EXPLAIN」を知ろう
MySQLには、SQL文の前に `EXPLAIN` というキーワードをつけて実行すると、「データベースがそのクエリをどうやって処理しようとしているか（実行計画）」を教えてくれる機能があります。
これをWordPressの実行時に自動でキャッチして、遅いクエリをあぶり出す「カスタムプロファイラー」を自分の手で作ってみましょう。
—
3. 実装：WP_Queryプロファイラーの構築
それでは、実際に動くコードを見ていきましょう。
以下のコードを、お使いのテーマの `functions.php` または自作プラグインに記述してみてください。
/
class WP_Query_Profiler {
// 遅いとみなす閾値（ミリ秒）
private const THRESHOLD_MS = 50.0;
public function __construct() {
// クエリの開始時間を計測
add_filter( ‘query’, [ $this, ‘capture_query’ ], 10, 1 );
}
/
- 発行されるSQLをフックして監視・分析する
/
public function capture_query( $sql ) {
// 管理画面やAjax、Cronを除外したい場合はここでガード条件を書きます
if ( is_admin() ) {
return $sql;
}
// SELECT文以外（INSERT, UPDATEなど）はスルー
if ( stripos( trim( $sql ), ‘SELECT’ ) !== 0 ) {
return $sql;
}
$start_time = microtime( true );
// クエリを実際に実行して結果を返す（フィルタの役割を邪魔しないため）
// ※注意: ここでは純粋なSQLの実行時間を測るため、フック内でさらにクエリを投げます
global $wpdb;
// EXPLAINを取得
$explain_results = $wpdb->get_results( “EXPLAIN {$sql}”, ARRAY_A );
$end_time = microtime( true );
$execution_time = ( $end_time – $start_time ) 1000; // ミリ秒に変換
// 閾値を超えた場合、またはインデックスが使われていない（type = ALL）場合にログを残す
if ( $execution_time > self::THRESHOLD_MS || $this->has_full_table_scan( $explain_results ) ) {
$this->log_bottleneck( $sql, $execution_time, $explain_results );
}
return $sql;
}
/
- EXPLAIN結果からフルテーブルスキャン（全件走査）が行われているか判定
/
private function has_full_table_scan( $explain_results ) {
if ( empty( $explain_results ) ) {
return false;
}
foreach ( $explain_results as $row ) {
// MySQLのEXPLAINで ‘type’ が ‘ALL’ の場合、インデックスが使われていません
if ( isset( $row[‘type’] ) && ‘ALL’ === $row[‘type’] ) {
return true;
}
}
return false;
}
/
- ボトルネック情報をデバッグログに記録
/
private function log_bottleneck( $sql, $execution_time, $explain ) {
$log_message = sprintf(
“[WP Query Profiler] ⚠️ 警告: 遅いクエリまたはフルテーブルスキャンを検出しました。\n実行時間: %.2f ms\nSQL: %s\n”,
$execution_time,
$sql
);
// デバッグ.logに出力 ( wp-config.php で WP_DEBUG_LOG が true の場合有効 )
if ( defined( ‘WP_DEBUG’ ) && WP_DEBUG ) {
error_log( $log_message );
}
}
}
// プロファイラーを起動！
new WP_Query_Profiler();
—
4. コードの意味と、初学者が陥りやすいポイント
このコードの重要なポイントを、いくつか噛み砕いて解説しますね。
① `query` フィルターの利用
WordPressはデータベースにSQLを投げる直前に、`query` というフィルターフックを用意してくれています。これを使うことで、システム中を流れるすべてのSQLを一度キャッチすることができます。まさに裏側の門番ですね。
② `EXPLAIN` の解析 (`has_full_table_scan`)
MySQLの `EXPLAIN` を実行すると、そのクエリがどのテーブルのどのインデックスを使ったのかが返ってきます。
その中の `type` という項目が `ALL` になっている場合、それは「インデックスを使えず、本棚の最初から最後まで全部の本をめくって探している状態」を意味します。これがパフォーマンス低下の最大の原因になるため、コード内で厳しく監視しています。
⚠️ 陥りやすい文法・設計エラー
ここで、他の言語から来た方がやりがちなミスを一つ。
> 「フィルターフックの中で、さらにデータベースにクエリを投げても大丈夫なの？」
今回のコードでは、`$wpdb->get_results( “EXPLAIN {$sql}” … )` と、フックの内部でさらにクエリを実行していますよね。
実はこれ、やりすぎると「プロファイラー自体のせいでサイトが重くなる」という本末転倒なバグ（オーバーヘッド）を生む原因になります。
そのため、本番環境で常時動かす場合は、今回のコードのように「管理画面を除外する」「一定以上の時間がかかったときだけ動かす」といったガードを必ず入れるようにしてくださいね。
—
5. ボトルネックを見つけたらどう直すのか？
プロファイラーが `wp-content/debug.log` に警告を吐き出してくれたとします。では、どうやって修正すればいいのでしょうか？
1. メタキー（カスタムフィールド）の検索を見直す
`meta_query` で数千件の投稿から値を探している場合、デフォルトではWordPressはインデックスを持っていません。もし可能であれば、カスタムフィールドではなく「タクソノミー（カスタム分類）」を使うように設計を変更すると、劇的に速くなります（タクソノミーのterm_relationshipsテーブルには最初から完璧なインデックスが貼られているためです）。
2. 不必要なクエリを走らせない
無駄な `new WP_Query()` を書いていないか、トランジェントAPI（キャッシュ）を使って結果を一時保存できないか検討しましょう。
—
まとめ
今回は、`WP_Query` の裏側を覗き見するカスタムプロファイラーの作り方を通して、データベースの実行計画（EXPLAIN）とパフォーマンス最適化の基本を解説しました。
「動けばいいや」ではなく、「裏側でMySQLがどう動いているか」を想像できるようになると、あなたはもう初級者を脱出し、一人前のプロフェッショナルエンジニアへの階段を確実に上っていますよ。
ぜひ、ご自身の開発環境で試して、ログにどんなSQLが流れているか観察してみてくださいね。それでは、快適なWordPress開発ライフを！