【入門編】初心者向け:WP_Queryで発行されるSQLをログ出力して「重いクエリ」を特定する最初の一歩 – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

こんにちは!WordPressの裏側の仕組みや、データベースがどう動いているのか気になってこのページに辿り着いたのですね。素晴らしい着眼点です!

他のプログラミング言語や一般的なWebフレームワークからWordPressに入った開発者の多くが、「なんだかサイトの表示が重いな……」と直面したとき、最初に迷子になりがちです。
でも大丈夫ですよ。ここをクリアすれば、WordPressのデータベース周りの基本はバッチリマスターできますからね。

今回は、WordPressの心臓部である `WP_Query` が裏側でどんなSQLを発行しているのかを丸裸にし、重いクエリを特定するための最初の一歩を、優しく紐解いていきましょう。

—

なぜ、あなたのWordPressは重くなるのか?

WordPressでサイトを作っていると、記事一覧やカスタム投稿を表示するために `new WP_Query()` や `query_posts()`、あるいはメインクエリといった形でデータベースにアクセスしますよね。

初心者の方がやりがちなのが、「とりあえず必要なデータを取得するコードを書いたけれど、裏側でどれくらいデータベースに負荷がかかっているか気付いていない」という状態です。

実は、WordPressは非常にリッチな機能を持っている反面、何気なく書いた1回の `WP_Query` が、裏側で複雑なSQL(JOINや子クエリなど)を大量に生み出していることがあります。

「目に見えないSQL」を可視化すること。それがパフォーマンスチューニングのすべての始まりなんです。

—

魔法の定数 `SAVEQUERIES` でSQLを覗き見する

WordPressには、開発者向けにデータベースへのクエリ(問い合わせ)をすべて記録しておいてくれる、とっておきのデバッグ機能が用意されています。

それが、定数 `SAVEQUERIES` です。

これを使うために、まずは設定ファイルである `wp-config.php` を覗いてみましょう。

1. `wp-config.php` でクエリの記録を有効化する

`wp-config.php` の中にある `/ 編集が必要なのはここまでです… /` という行よりも上の位置に、以下のコードを1行追加してください。

/

  • データベースクエリの記録を有効化 (デバッグ用)
  • 本番環境ではパフォーマンス低下の原因になるため、必ずfalseにするか削除してください。

/
define( ‘SAVEQUERIES’, true );

これだけで、WordPressはこれ以降に実行されたすべてのSQL文、その実行にかかった時間(秒数)、そして「どの関数のどの行から呼ばれたか(コールスタック)」をメモリ上に保存し始めます。

—

実際に発行されたクエリを出力して確認してみよう

記録ができるようになったら、次はそれを画面に出力して確認してみましょう。
例えば、テーマの `footer.php` や、検証用のカスタムページテンプレートなどに、以下のコードを貼り付けてみてください。

‘;
echo ‘

— WP_Query & Database Debug Inspector —

‘;
echo ‘

総クエリ数: ‘ . count( $wpdb->queries ) . ‘

‘;

// 実行されたクエリの配列をループして中身を確認
foreach ( $wpdb->queries as $index => $query ) {
$sql_statement = $query[0]; // 実行されたSQL文
$execution_time = $query[1]; // 実行時間(秒)
$call_stack = $query[2]; // どこから呼ばれたか

echo ‘


‘;
echo ‘[‘ . ( $index + 1 ) . ‘] 実行時間: ‘ . round( $execution_time 1000, 2 ) . ‘ ms
‘;
echo ‘' . esc_html( $sql_statement ) . '
‘;
echo ‘呼び出し元: ‘ . esc_html( $call_stack ) . ‘‘;
}

echo ‘

‘;
}
?>

このコードのポイント

  • `global $wpdb;`: WordPressのデータベース操作を司るグローバルオブジェクトを呼び出しています。
  • `$wpdb->queries`: `SAVEQUERIES` が `true` のとき、ここにこれまでの全クエリが配列として蓄積されます。
  • 実行時間 (`$query[1]`): 秒単位で記録されているため、` 1000` をしてミリ秒(ms)に変換すると直感的に分かりやすくなりますよね。

—

「重いクエリ」をどうやって見つけるのか?

出力結果が見えるようになったら、次に行うべきは「どのクエリがボトルネック(悪者)か」の特定です。

次のような観点でログを眺めてみてください。

1. 実行時間が突出して長いものがないか?

  • 例えば、他のクエリが `0.001ms` なのに、あるクエリだけ `0.250ms` かかっている場合、そこにインデックス(索引)が効いていない可能性や、データ量が多すぎてフルスキャン(全件走査)している可能性があります。

2. 同じようなクエリが何回も実行されていないか?(N+1問題の予兆)

  • リストを表示する際、ループの中で毎回個別データを取得するような雑なクエリ(重複クエリ)が発行されていないかチェックします。

陥りやすい文法・設定エラー

ここで、初心者がよくハマるポイントをいくつか共有しておきますね。

  • 本番環境でつけっぱなしにしない!

`SAVEQUERIES` は、すべてのSQLを配列としてメモリ上に保持し続けるため、アクセス数が多い本番環境でこれを有効にすると、メモリを大量消費してサイトが極端に重くなったり、最悪の場合はダウンしたりします。 検証が終わったら、必ず `false` に書き換えるか、行ごと削除する癖をつけてくださいね。

  • 「SQL文の中身」と「PHPの書き方」を混同しない

出力されたSQLを見て「あ、ここで `meta_query` を複雑にしすぎて `JOIN` が膨らんでいるんだな」と気づくことが大切です。SQLの構造が見えると、`WP_Query` の引数の書き方をどう改善すればいいか(例:不要な `tax_query` を削る、`no_found_rows => true` でページネーション計算を省くなど)が見えてきます。

—

おわりに

お疲れ様でした!
「WordPressが裏側でどんなSQLを喋っているのか」を自分の目で確認できた瞬間から、あなたは単なる「WordPressの使い方を知っている人」から、「WordPressのシステムをコントロールできるエンジニア」へと一歩踏み出しています。

まずはローカル環境などで `SAVEQUERIES` を試して、ご自身が書いたコードがどんなSQLを生み出しているのか覗き見してみてください。
ここをクリアすれば、データベースのインデックスチューニングや高度なキャッシュ戦略といった、さらに先の世界がグッと楽しくなりますよ。

分からないことがあれば、いつでも何度でも質問してくださいね。応援しています!

タイトルとURLをコピーしました