クエリキャッシュは、SELECT 文とその結果をメモリに保存し、まったく同じ文が来たときにテーブルを読まずに結果を返す仕組みです。ただし2026年10月時点で、使える環境は限られています。
- MySQL: クエリキャッシュは 5.7.20 で非推奨になり、MySQL 8.0 で削除されました。8.0 以降に
query_cache_typeなどの変数はありません。 - MariaDB: 機能は残っていますが、既定で無効（
query_cache_type = OFF）です。MariaDB の公式ドキュメントは、多コアのサーバーではロック待ちの悪影響が利点を上回ることが多いとして、有効化を勧めていません。
この記事では、まず自分のデータベースで使えるかを確かめ、MariaDB で試す場合の設定と効果の測り方、WordPress で代わりに使うべきキャッシュを説明します。
使っているデータベースを確認する
SELECT VERSION();
SHOW VARIABLES LIKE 'have_query_cache';
SHOW VARIABLES LIKE 'query_cache%';VERSION()が8.0.x以降の MySQL なら、クエリキャッシュは存在しません（SHOW VARIABLES LIKE 'query_cache%'は空の結果になります）。この場合は後半の「WordPressで代わりに使うキャッシュ」へ進んでください。10.x-MariaDBや11.x-MariaDBと表示され、have_query_cacheがYESなら設定できます。
クエリキャッシュの仕組みと制限
設定する前に、効く場面と効かない場面を押さえておきます。
- 文字列として一字一句同じクエリにしか当たりません。空白やコメントが違うだけでも別のクエリとして扱われます。
- テーブルに書き込みがあると、そのテーブルを使うキャッシュ結果はすべて破棄されます。古い結果が返ることはありませんが、更新の多いテーブルではほとんど当たりません。
NOW()・RAND()・UUID()などの非決定的な関数を含むクエリ、一時テーブルを使うクエリ、ユーザー変数を使うクエリ、SELECT ... FOR UPDATEなどはキャッシュされません。- 参照も登録も一つのロック（ミューテックス）を順番に取るため、同時接続が多いと待ちが発生します。
WordPress はコメント・投稿の更新、wp_options のトランジェント書き込みなどで頻繁にテーブルを書き換えるため、クエリキャッシュの当たり率は上がりにくい傾向があります。設定後は次の「効果を測る」で数値を見て判断してください。
MariaDBでクエリキャッシュを有効にする
一時的に試す（再起動で元に戻る）
MariaDB では、起動時に無効でも実行中に有効化できます。
SET GLOBAL query_cache_size = 67108864; -- 64MB
SET GLOBAL query_cache_type = ON;
SHOW VARIABLES LIKE 'query_cache%';query_cache_size は 1024 の倍数に切り捨てられます。小さすぎる値を指定すると割り当てに失敗し、サイズが 0 になります（警告が出ます）。
設定ファイルで恒久化する
Debian / Ubuntu の MariaDB パッケージでは /etc/mysql/mariadb.conf.d/50-server.cnf の [mysqld] セクションに書きます（RHEL 系では /etc/my.cnf.d/mariadb-server.cnf など。配置はディストリビューションで異なります）。
[mysqld]
query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 1Msudo systemctl restart mariadb各変数の意味は次のとおりです。
| 変数 | 意味 |
|---|---|
query_cache_type |
0(OFF)=使わない、1(ON)=キャッシュできるものはすべて保存（SQL_NO_CACHE を除く）、2(DEMAND)=SQL_CACHE を付けたクエリだけ保存 |
query_cache_size |
クエリキャッシュ全体に割り当てるメモリ量 |
query_cache_limit |
1件の結果としてキャッシュできる最大サイズ。これより大きい結果は保存しない |
query_cache_min_res_unit |
結果を保存するブロックの最小単位。小さいと断片化とロックが増え、大きいとメモリの無駄が増える |
query_cache_strip_comments |
照合前にコメントを取り除く（コメントだけ違うクエリを同じものとして扱う） |
クエリキャッシュには有効期限を決める変数（query_cache_expiry のようなもの）はありません。保存した結果は、テーブルの更新とメモリ不足でだけ結果が捨てられます。
サイズは大きくすれば良いわけではありません。大きすぎると結果の破棄やロック待ちの負担が増えることがあるため、数十MB程度から始めて、次の数値を見て調整します。
効果を測る
SHOW GLOBAL STATUS LIKE 'Qcache%';| ステータス変数 | 意味 |
|---|---|
Qcache_hits |
キャッシュから結果を返した回数 |
Qcache_inserts |
キャッシュに登録した回数 |
Qcache_not_cached |
キャッシュできなかったクエリの数 |
Qcache_lowmem_prunes |
メモリ不足で古い結果を捨てた回数 |
Qcache_free_memory |
空いているメモリ量 |
Qcache_queries_in_cache |
保存されているクエリの数 |
Qcache_free_blocks / Qcache_total_blocks |
空きブロック数 / 全ブロック数。空きの割合が大きいと断片化している |
判断の目安:
Qcache_hitsがQcache_insertsより十分に多くなければ、登録の手間ばかりかかっています。無効に戻すことを検討します。Qcache_lowmem_prunesが増え続けるなら、サイズが足りないか、キャッシュに向かない負荷です。- 有効化の前後で、ページの応答時間やスロークエリの件数を比べてください。数値が改善しない、または悪化するなら無効に戻します。
キャッシュの整理には次の文を使います。
FLUSH QUERY CACHE; -- 断片化を解消する（保存済みの結果は消さない）
RESET QUERY CACHE; -- 保存済みの結果をすべて消す無効に戻すときは、設定ファイルの query_cache_type = 0 と query_cache_size = 0 にして再起動します。
WordPressで代わりに使うキャッシュ
MySQL 8.0 以降を使っている場合や、クエリキャッシュの効果が出ない場合は、アプリケーション側でキャッシュします。
- 永続オブジェクトキャッシュ: WordPress はオブジェクトキャッシュ（
wp_cache_get()/wp_cache_set()）を持っていますが、標準では1リクエストの間しか保持しません。Redis や Memcached をバックエンドにするドロップイン（wp-content/object-cache.php）を入れると、オプションや投稿のデータをリクエストをまたいで再利用でき、データベースへの問い合わせが減ります。WordPress 6.1 以降は「サイトヘルス」で、条件に応じて永続オブジェクトキャッシュの利用を勧める項目が表示されます。 - ページキャッシュ: ログインしていない訪問者向けに、生成済みの HTML を保存して返します。PHP とデータベースの処理自体を省けるため、効果は大きくなりやすい方法です。
- 遅いクエリそのものの改善: どのクエリが遅いかは Query Monitor プラグインで確認できます。インデックスの追加や不要なプラグインの見直しの方が、キャッシュより根本的な対策になります。
設定手順は次の記事を参照してください。
注意点
- クエリキャッシュに割り当てたメモリは InnoDB バッファプールなどと同じサーバーのメモリから取られます。メモリの少ない VPS では、バッファプールを削ってまで大きくしないでください。
- 共用サーバーやマネージドデータベースでは、
SET GLOBALの権限がなく、設定を変えられないことがあります。 - MariaDB から MySQL 8.0 以降へ移行する予定がある場合、クエリキャッシュの設定は移行先で使えません。設定ファイルに残すと MySQL が起動しなくなるため、移行時に削除してください。
まとめ
- クエリキャッシュは MySQL 8.0 で削除済みで、MariaDB では既定で無効、公式にも有効化は勧められていません。
- MariaDB で試すなら
query_cache_typeとquery_cache_sizeを設定し、Qcache_hitsとQcache_lowmem_prunesを見て残すか判断します。 - WordPress の高速化では、永続オブジェクトキャッシュ・ページキャッシュ・遅いクエリの改善を優先してください。