WordPressの深淵を覗く：Object CacheとMySQLクエリキャッシュの相克を制する
多くのエンジニアが「WordPressは遅い」と口にする。しかし、それはWordPressの設計思想を理解せず、ただ重いクエリを投げ続けている開発者の怠慢に過ぎない。
今日は、`wp_posts` や `wp_postmeta` といったコアテーブルへのアクセスを最適化し、MySQLのクエリキャッシュに頼ることなく、アプリケーション層で真の高速化を実現するアーキテクチャについて語ろう。
—
1. 幻想としての「MySQLクエリキャッシュ」
まず、厳しい現実を突きつける。MySQLのクエリキャッシュは、現在では多くの環境で廃止、あるいは推奨されていない。なぜか？ テーブル単位のロックによる排他制御がボトルネックとなり、高トラフィック環境ではかえってスループットを低下させるからだ。
WordPressがコアとして備える `WP_Object_Cache`（内部キャッシュ）は、このMySQLの弱点を補完するために存在する。我々が意識すべきは「データベースへの物理アクセスをいかにしてゼロにするか」という一点に尽きる。
—
2. wp_postmeta：EAVモデルの罠と回避戦略
`wp_postmeta` はEAV (Entity-Attribute-Value) モデルで実装されている。メタデータを増やすほど、`SELECT FROM wp_postmeta WHERE post_id = X` のクエリは肥大化し、結合負荷が増大する。
ここで重要なのは、「キャッシュの汚染（Cache Pollution）」を避けつつ、キャッシュの有効期限を制御する設計だ。
実践的コード：メタデータ取得の最適化パターン
以下のコードは、単なる `get_post_meta()` ではない。キャッシュの生存期間と、クエリの再実行を最小化する設計を意識している。
/
- 堅牢なメタデータ取得キャッシュ層
- データベースへのアクセスを最小化し、Object Cacheを最大限活用する
/
function get_optimized_post_meta(int $post_id, string $key, bool $single = true) {
$cache_key = “custom_meta_{$post_id}_{$key}”;
$value = wp_cache_get($cache_key, ‘post_meta_group’);
if (false === $value) {
$value = get_post_meta($post_id, $key, $single);
// 外部キャッシュ（Redis等）へ保存、有効期限は必要に応じて調整
wp_cache_set($cache_key, $value, ‘post_meta_group’, HOUR_IN_SECONDS);
}
return $value;
}
/
- 更新時には必ずキャッシュをパージする
- このフックを忘れると、不整合地獄が待っている
/
add_action(‘updated_post_meta’, function($meta_id, $object_id, $meta_key) {
wp_cache_delete(“custom_meta_{$object_id}_{$meta_key}”, ‘post_meta_group’);
}, 10, 3);
—
3. なぜ「非同期API連携」でこの設計が不可欠なのか
外部APIから取得したデータを `wp_postmeta` に保持し、それをREST APIで返すような構成の場合、以下の悪循環が頻発する。
1. APIレスポンス待ち → PHPプロセス滞留 → DB接続数逼迫。
2. Object Cacheのミス → DBへの再クエリ → MySQLクエリキャッシュの無効化（テーブル更新時）。
この連鎖を断つには、「データベースを書き込み専用、キャッシュを読み取り専用」と定義し、分離することだ。
—
4. テクニカルリードからの提言：パフォーマンスを掌握する3つの指針
① `get_posts` / `WP_Query` の引数を疑え
`’no_found_rows’ => true` を指定しているか？ ページネーションが不要なクエリで SQL_CALC_FOUND_ROWS を発行するのは、DBに対して「無駄な全件数カウント」を強要する行為だ。これだけでパフォーマンスは劇的に変わる。
② クエリの断片化を許すな
`post_meta` を個別取得するためにループ内でクエリを投げるのは最悪のアンチパターンだ。`update_meta_cache` フックを使い、必要なメタデータを一括でメモリにロードする設計に変更せよ。
③ キャッシュの「有効期限」は戦略的であるべきだ
すべてのキャッシュに同じ `HOUR_IN_SECONDS` を与えてはならない。
- 頻繁に更新されるデータ: タイムスタンプ管理による手動パージ。
- 滅多に更新されない静的データ: 長期間の Object Cache 保持。
—
結論：エンジニアは「データ構造」を支配せよ
WordPressのコアファイルを開いてみればわかる。`wp-includes/class-wp-query.php` は極めて洗練されたクエリビルダーだ。しかし、それを活かすも殺すも、開発者が書くクエリの質次第である。
「なんとなく動く」コードから卒業し、データベースの物理構造とキャッシュのライフサイクルを頭の中で並列処理できるエンジニアになれ。それこそが、WordPressという巨大なプラットフォームを「掌握」する唯一の道だ。
コードは嘘をつかない。あなたの設計が、そのままプロダクション環境の負荷として跳ね返ってくる。さあ、次はどのクエリを最適化する？