こんにちは！WordPressの内部構造やパフォーマンス最適化の旅へようこそ。
今回は、ほかのプログラミング言語からWordPressの世界に入ってきた方や、「そろそろデータベースの裏側まで完全理解したい！」と意気込んでいる上級者向けに、少しディープで最高にエキサイティングなテーマをお届けします。
取り上げるのは、MySQL（InnoDB）の「インデックス・コンプレッション（テーブル圧縮）」が、私たちの愛する `WP_Query` にどのような影響を与えるか、そのトレードオフの真実です。
「えっ、WordPressってただPHPを書くだけじゃないの？」と思ったそこのあなた。実は、大規模サイトや高負荷な環境を支えるシニアエンジニアは、PHPコードだけでなく、その下にあるデータベースの物理層までコントロールしているんです。
ここをクリアすれば、あなたのWordPressパフォーマンスチューニングのスキルは間違いなく一皮むけますよ。一緒に優しく、深く、紐解いていきましょう！
—
1. そもそも `WP_Query` と InnoDB の裏側で何が起きているのか？
私たちが普段何気なく書いている次のようなコード、ありますよね。
‘post’,
‘posts_per_page’ => 5,
‘orderby’ => ‘date’,
‘order’ => ‘DESC’,
);
$query = new WP_Query( $args );
このコードが実行されるとき、WordPressの内部（`WP_Query` クラス）では、MySQLに対して次のようなSQL（概念的なイメージ）が発行されています。
SELECT FROM wp_posts
WHERE post_type = ‘post’ AND post_status = ‘publish’
ORDER BY post_date DESC
LIMIT 5;
ここでデータベース（InnoDB）は、ハードディスク（またはSSD）などのストレージからメモリ（InnoDBクエリキャッシュやバッファプール）へデータを読み込みます。
このとき、「データ量が増えれば増えるほど、ディスクI/O（読み書きの回数と重さ）がボトルネックになる」というのは、エンジニアの常識ですよね。そこで登場するのが、データベースの容量を物理的に圧縮する「インデックス・コンプレッション（ROW_FORMAT=COMPRESSED）」という技術です。
—
2. インデックス・コンプレッションの基本と「トレードオフ」
インデックス・コンプレッションとは、InnoDBのテーブルやインデックスをストレージ上で圧縮して保存する機能のことです。
— 例：wp_posts テーブルを圧縮形式に変更するSQL
ALTER TABLE wp_posts ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;
これを聞くと、「おっ、ディスク容量が節約できて一石二鳥じゃないか！」と思いますよね。もちろん、ディスク使用量が減るという絶大なメリットがあります。
しかし、ここにはプロが知っておくべき「CPUとメモリのトレードオフ」という裏の顔が存在します。
表の顔：ストレージI/Oの削減
- メリット: ディスク上のデータサイズが小さくなるため、ディスクからメモリ（Buffer Pool）へデータを読み込む際のI/O負荷が劇的に軽減されます。
裏の顔：CPU負荷（解凍コスト）の増大
- デメリット: `WP_Query` が実行され、圧縮されたページ（Page）にアクセスするたびに、MySQLはCPUを使ってデータを「解凍（Decompression）」しなければなりません。
つまり、「ディスクI/Oは減るけれど、CPU使用率が跳ね上がる」というトレードオフがここで発生するわけです。
—
3. `WP_Query` における具体的な影響とコードからのアプローチ
では、このトレードオフは `WP_Query` のパフォーマンスにどう直結するのでしょうか？
例えば、カスタムフィールド（メタデータ）を大量に使う複雑な `WP_Query` を考えてみましょう。
‘product’,
‘meta_query’ => array(
array(
‘key’ => ‘_stock_status’,
‘value’ => ‘instock’,
‘compare’ => ‘=’,
),
),
‘posts_per_page’ => 20,
);
$complex_query = new WP_Query( $args );
このクエリが走るとき、`wp_postmeta` テーブルも頻繁に参照されます。もし `wp_postmeta` が過度に圧縮されていると、次のような現象が起きます。
1. バッファプールのヒット率低下: 圧縮ページはメモリ（InnoDB Buffer Pool）上でも圧縮された状態で保持されることがあり、頻繁に解凍・圧縮が繰り返されるため、メモリの効率（キャッシュ効率）が悪化することがあります。
2. CPUバウンドなボトルネック: 同時アクセス数（トラフィック）が多いサイトでは、MySQLのCPU使用率が100%に張り付き、結果的に `WP_Query` のレスポンスが遅延します。
初学者が陥りがちな文法・設計エラー
他の言語（例えば、単なるCRUDアプリ）から来た開発者がやりがちなのが、「とりあえず全てのテーブルを圧縮しておけば省スペースで安全だろう」という誤った思い込みです。
- 誤ったアプローチ: トラフィックが多い高頻度な更新・参照テーブル（`wp_posts`, `wp_postmeta`）に一律で強い圧縮をかける。
- 正しいアプローチ: アクセス頻度が低く、容量が大きいログテーブルやアーカイブ用のテーブルには圧縮を検討し、リアルタイム性が求められるトランザクション性の高いテーブルでは、CPU負荷とI/Oのバランスを慎重にベンチマーク測定する。
—
4. 現場で使える！パフォーマンス最適化の実践知見
では、私たちはこのデータベースの物理層の特性を踏まえて、どのようにWordPressを設計・最適化すべきでしょうか？
① `WP_Query` の結果をオブジェクトキャッシュに逃がす
データベースへのヒット自体を減らすのが、最も確実な最適化です。Transient APIやMemcached/Redisなどの外部オブジェクトキャッシュを利用し、`WP_Query` の結果（またはSQLの実行結果）をキャッシュしましょう。
5,
‘orderby’ => ‘comment_count’,
));
$posts = $query->posts;
// 1時間キャッシュする
wp_cache_set( $cache_key, $posts, ‘custom_query’, HOUR_IN_SECONDS );
}
return $posts;
}
② データベースのインデックスチューニングを優先する
テーブル圧縮に頼る前に、まずは `WP_Query` が適切にインデックス（INDEX）を使っているかを確認してください。`EXPLAIN` 句を使って、フルテーブルスキャン（全件走査）が起きていないかをチェックするのがプロの鉄則です。
— 実際のクエリの前に EXPLAIN をつけて確認
EXPLAIN SELECT FROM wp_posts WHERE post_type = ‘post’ AND post_status = ‘publish’;
インデックスが適切に張られていれば、不要なデータ読み込みが防げるため、テーブル圧縮によるCPU負荷のリスクを冒さなくても高速なレスポンスを実現できます。
—
まとめ
いかがでしたでしょうか？今回はInnoDBの「インデックス・コンプレッション」が `WP_Query` に与える影響について、CPUとI/Oのトレードオフという観点から解説しました。
- インデックス・コンプレッションはディスク容量を減らすが、解凍のためのCPUコスト（トレードオフ）が発生する。
- トラフィックが多いサイトの `wp_posts` や `wp_postmeta` への安易な適用は、CPUボトルネックを招く危険がある。
- まずは適切なインデックス設計と、オブジェクトキャッシュの活用を優先すべき。
ここをクリアできれば、単に動くコードを書くだけでなく、「なぜこの構成がスケールするのか」を説明できる真のフルスタックエンジニアに近づけます。
一歩一歩、深い知識を自分のものにしていきましょう。あなたのWordPress開発の旅を、これからも応援しています！