WordPressを「鈍重なCMS」と呼ぶのは、SQLを正しく読めないエンジニアの言い訳だ。
WordPressのパフォーマンスチューニングにおいて、`WP_Query`をブラックボックスとして扱うのは今日で終わりにしよう。我々が書くコードが、データベースのストレージエンジンにどのような「命令」として届いているのか。この視点がないエンジニアは、たとえコードが動いたとしても、スケールするシステムを構築することはできない。
今日は、`WP_Query`が発行するSQLを解剖し、EXPLAIN句を用いて「なぜそのクエリがサイトを停止させるのか」を特定し、インデックスレベルから最適化する極限の手法を伝授する。
—
1. 敵を知る：WP_Queryは「SQL翻訳機」に過ぎない
`WP_Query`は万能ではない。複雑なパラメータを渡せば渡すほど、WordPressは内部でJOINを繰り返し、巨大なサブクエリを生成する。
特に注意すべきは、`meta_query`や`tax_query`だ。これらは`wp_postmeta`テーブルとのJOINを強いるため、適切なインデックスがなければ、MySQLは全行をスキャンする「フルテーブルスキャン（type: ALL）」に突入する。
まずは、自分の書いたコードが発行しているSQLを確認せよ。以下のコードを開発環境の適当な箇所に仕込み、クエリの内容を可視化する。
// デバッグ用：最後に実行されたクエリをログ出力する
add_action(‘wp_footer’, function() {
global $wpdb;
if (defined(‘SAVEQUERIES’) && SAVEQUERIES) {
error_log($wpdb->last_query);
}
});
—
2. EXPLAIN解析：ボトルネックの外科手術
取得したSQLをMySQLクライアント（phpMyAdminやSequel Aceなど）に貼り付け、先頭に `EXPLAIN` を付与して実行せよ。注目すべきは以下の項目だ。
- type: `ALL` なら危険信号。インデックスが効いていない。`ref` や `eq_ref` を目指せ。
- possible_keys: 考慮されたインデックス。ここが `NULL` ならインデックス設計が破綻している。
- key: 実際に使用されたインデックス。
- rows: ここが最重要だ。 MySQLがレコードを特定するためにスキャンした行数。10万行のテーブルでここが「9万」であれば、そのクエリはサイトの寿命を削っている。
—
3. 実践：インデックスを考慮した「美しい」設計パターン
例えば、「特定のメタキーを持ち、かつ特定のタクソノミーに属する投稿」を取得する際、安易に `WP_Query` を書くと、`wp_postmeta` への多重JOINで性能が崩壊する。
非効率なパターン（アンチパターン）
$query = new WP_Query([
‘meta_query’ => [[‘key’ => ‘event_date’, ‘value’ => ‘2023-12-31’, ‘compare’ => ‘>’]],
‘tax_query’ => [[‘taxonomy’ => ‘event_cat’, ‘field’ => ‘slug’, ‘terms’ => ‘premium’]]
]);
このコードは、`postmeta` テーブルをスキャンする際、`meta_key`と`meta_value`の結合インデックスがない限り、全行を舐める。
解決策：インデックスの最適化とクエリの分離
物理的にデータベースのインデックスを張ることを忘れるな。
— meta_key と meta_value の複合インデックスを追加する（プロダクションでの必須儀礼）
ALTER TABLE wp_postmeta ADD INDEX idx_key_value (meta_key, meta_value(20));
さらに、コードレベルでは「不要なデータ取得の抑制」と「キャッシュ」を徹底する。
/
- パフォーマンスを意識した堅牢なクエリ取得パターン
/
function get_optimized_event_posts() {
// 1. Transient APIを活用し、DBへの負荷を最小化する
$cache_key = ‘optimized_events_list’;
if (false === ($posts = get_transient($cache_key))) {
// 2. WP_Queryは必要なフィールドのみを取得する
$posts = get_posts([
‘post_type’ => ‘event’,
‘posts_per_page’ => 10,
‘meta_key’ => ‘event_date’, // 個別のキー指定で最適化を促す
‘orderby’ => ‘meta_value’,
‘no_found_rows’ => true, // ページネーション不要ならSQLを軽量化する最強のフラグ
‘update_post_meta_cache’ => false, // メタデータ取得が不要ならOFFにする
]);
set_transient($cache_key, $posts, HOUR_IN_SECONDS);
}
return $posts;
}
—
結論：なぜ我々はここまでするのか
`’no_found_rows’ => true` を指定するだけで、MySQLは `SQL_CALC_FOUND_ROWS` という重い処理をスキップする。この小さな一行が、トラフィックが急増した瞬間にサーバーを救う鍵となる。
WordPressは、使い方次第で「重いCMS」にも「超高速なWebアプリケーション基盤」にもなる。データベースのインデックス構造を理解し、`WP_Query`が発行するSQLの実行計画（EXPLAIN）を読み解く力こそが、プロフェッショナルとアマチュアを分かつ境界線だ。
今日から、コードを書く前に「このクエリはデータベースに何行のスキャンを強いるのか？」と自問せよ。それが、君が真のWordPressエンジニアへ進化するための第一歩だ。