MySQLのquery_cacheが効かない場合の対処法

Question

■実現したいこと
周期的に重たいSelect文を発行するシステムで、query_cacheを利用して、重たいSelect文の応答時間短縮やサーバー負荷を軽くしたいと思っています。
※重たいSelect文の中身は固定ですが、拾ってくるテーブルの一部のレコードは絶えず変化しています。

■今の状況
重たいSelect文の応答速度は変わらず（３５秒程度）、キャッシュが利用されていないように見受けられます。
キャッシュが利用されるようにしたいのですが、何が間違っているのかよく分かりません。

■再現手順
MySQLのバージョンです。　※ Dockerで環境を作っています。

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.1.73    |
+-----------+

キャッシュの設定はこのようになっています。

mysql> SHOW VARIABLES LIKE '%query_cache%';
+------------------------------+---------+
| Variable_name                | Value   |
+------------------------------+---------+
| have_query_cache             | YES     |
| query_cache_limit            | 1048576 |
| query_cache_min_res_unit     | 4096    |
| query_cache_size             | 999424  |
| query_cache_type             | DEMAND  |
| query_cache_wlock_invalidate | OFF     |
+------------------------------+---------+

上記の状態で、重たいSelect文を下記のように実行しています。
※ 何回実行しても、概ね35秒位で帰ってきます。

select SQL_CACHE ・・・・・

キャッシュの利用状況を確認すると、「Qcache_not_cached」がカウントアップしていきます。
ここで、キャッシュが使われていないと判断しています。

mysql> SHOW STATUS LIKE 'Qcache%';
+-------------------------+--------+
| Variable_name           | Value  |
+-------------------------+--------+
| Qcache_free_blocks      | 1      |
| Qcache_free_memory      | 982232 |
| Qcache_hits             | 0      |
| Qcache_inserts          | 0      |
| Qcache_lowmem_prunes    | 0      |
| Qcache_not_cached       | 9      |
| Qcache_queries_in_cache | 0      |
| Qcache_total_blocks     | 1      |
+-------------------------+--------+

■質問事項
0. Select文で使用するテーブルの一部が変化(insert,update)している場合、query_cacheを利用することは負荷軽減・速度改善に寄与しますでしょうか。
0. 上記の設定やSelect文の実行方法を行っても、query_cacheが利用されていないと思われる場合、何をチェックすればよろしいでしょうか。

Answer 1

1. について回答いたします。

Select文で使用するテーブルが更新された場合は、クエリキャッシュに格納されている結果はクリアされます。つまり、ヒットしません。
これは、データが変更になった後に、同じSelect文でも結果が異なるため、クエリキャッシュが使えないという考えです。

Comments

[akihico]

ありがとうございます。そもそもの話、クエリキャッシュは有効ではないことが分かりました。
クエリキャッシュに着目する発端となった課題については決着がつきました。

2.については、試験環境なので、実はテーブルは更新されていない状況です。
技術的な興味があるので、引き続きご回答を待ちたいと思います。

[MAKOTO_MOBY]

mysql> SHOW STATUS LIKE 'Qcache%';
の結果を見ると、
| Qcache_inserts | 0 | クエリキャッシュにインサートされたクエリが0．
| Qcache_queries_in_cache | 0 |　キャッシュ内に存在するクエリが０
ですので、結果はクエリキャッシュに入っていないと思われます。

原因の特定はできませんが、
可能性として、Selectの結果のデータサイズが、設定されておりれるクエリキャッシュのサイズ（999,424Byte)よりも大きいので、キャッシュされないのかもしれません。

[akihico]

なるほどです。
何をキャッシュしているのか？というところがポイントだと感がていますが、
当初はSelect文の結果だと思っていました。
ところが、頂いたご回答からすると、関係するテーブルをキャッシュしてると想定され、
そうなりますと、かなり大きなデータ量をキャッシュしようとしている・・・と思っているところです。

[MAKOTO_MOBY]

私の書き方が悪かったようです。申し訳ありません。キャッシュされるのはSelectの結果です。

ちなみに、クエリキャッシュの機能は、8.0以降から無くなる予定です。

[akihico]

ご丁寧に、すみません。selectの方がキャッシュされるのですね。
いずれ終息する機能ということですと、クエリキャッシュに頼らない方が良いという気持ちになってきました。ひとまず、疑問点は概ねクリアになりました。ありがとうございますm(_ _)m