こんにちは。WordPressの深淵へようこそ。
WordPressをただの「CMS」として捉えているうちは、本当のパワーは見えてきません。WordPressは、データベースという「記憶」を、キャッシュという「反射」で高速化する、極めて高度なエンジンです。
今日は、多くの開発者がなんとなく使っている「データ取得」の裏側で、MySQLとWordPressがどう会話しているのか。その核心である「データベースとキャッシュの相関関係」を紐解いていきましょう。ここを理解すれば、あなたの書くコードは劇的に速くなります。
—
1. データベースの物理構造：`wp_posts` と `wp_postmeta` の関係
WordPressの心臓部である `wp_posts` テーブルは、投稿、固定ページ、カスタム投稿タイプを全て飲み込む巨大なコンテナです。
- `wp_posts`: 記事のタイトルや本文など、共通の属性を保持。
- `wp_postmeta`: 記事に付随する「カスタムフィールド」という個別の属性を、縦持ち（EAVモデル）で保持。
ここで重要なのは、「メタデータが必要なとき、WordPressは追加のJOINや個別クエリを投げる」という事実です。
陥りやすい罠：N+1問題
ループの中で `get_post_meta()` を呼び出すと、そのたびにMySQLへのクエリが発行されます。10件の記事を表示するだけで、データベースと11回も会話することになるのです。これがパフォーマンス低下の最大の要因です。
—
2. MySQLクエリキャッシュ vs WordPress Object Cache
ここが本日の核心です。二つの「キャッシュ」がどう協力し、時に競合するのかをイメージしてください。
MySQL クエリキャッシュ（物理層）
MySQL自体が持っている機能です。「同じSQL文が来たら、計算せずに結果を返す」という仕組みですが、実は最新のMySQL 8.0では廃止されています。 なぜなら、テーブルが更新されるたびにキャッシュがすべて無効化され、むしろオーバーヘッドが大きすぎるからです。
WordPress Object Cache（アプリケーション層）
WordPressがメモリ（RedisやMemcachedなど）を活用してデータを保持する仕組みです。
- `wp_posts` からデータを一度取得したら、その結果をメモリ上に保存。
- 次回同じIDの投稿が必要なときは、MySQLにすら行かず、メモリから直接取得します。
—
3. 実践：どうすれば「爆速」を実現できるのか？
開発現場で最も重要なのは、「いかにMySQLへのクエリを減らし、Object Cacheを有効活用するか」です。
悪い例：ループ内で個別取得
$posts = get_posts([‘post_type’ => ‘product’]);
foreach ($posts as $post) {
// 毎回データベースに問い合わせが発生！
echo get_post_meta($post->ID, ‘price’, true);
}
良い例：Object Cacheの恩恵を受ける
WordPressには `get_posts` 実行時に、関連するメタデータを一括でキャッシュする仕組みがあります。
$args = [
‘post_type’ => ‘product’,
‘update_post_meta_cache’ => true, // これが重要！
‘update_post_term_cache’ => true,
];
$posts = get_posts($args);
// すでにキャッシュされているため、データベースへの追加アクセスはゼロです
foreach ($posts as $post) {
echo get_post_meta($post->ID, ‘price’, true);
}
—
4. 押さえておくべき「キャッシュの更新」という作法
キャッシュは魔法ではありません。「更新」を忘れると、古い情報が残り続けます。
WordPressには `clean_post_cache($post_id)` という関数があります。投稿が更新された際に、この関数が自動的に呼ばれ、Object Cacheが破棄されます。これにより、次のアクセスで最新のデータがMySQLから再取得されるわけです。
ここをマスターするためのチェックリスト
1. `WP_Query` を使う: `get_posts` や `WP_Query` は、内部で適切にキャッシュを管理しています。生SQL（`$wpdb->get_results`）を投げると、キャッシュの恩恵をすべて自分で実装しなければなりません。
2. `transient API` を活用する: 複雑な計算結果や、外部APIのレスポンスは `set_transient()` で保存しましょう。これがObject Cacheの「手動管理版」です。
3. Redisを導入する: 標準のObject Cacheはプロセスが終わると消滅します。永続化可能な Redis をバックエンドに指定するだけで、サイトの応答速度は劇的に向上します。
—
最後に：エンジニアとしての視座
データベースとキャッシュの関係を理解することは、「システムに無駄な仕事をさせない」という哲学を学ぶことと同じです。
MySQLという重厚な図書館へ毎回本を探しに行くのではなく、手元のデスク（Object Cache）に資料を置いておく。この意識を持つだけで、あなたのコードは「ただ動くもの」から「洗練されたシステム」へと進化します。
ここをクリアすれば、WordPress開発の景色は一変します。さあ、次はどの深淵を覗いてみましょうか？ 応援していますよ！