MySQL查詢緩存

一、查詢緩存說明

MySQL Query Cache是用來緩存我們所執行的SELECT語句以及該語句的結果集，MySql在實現Query Cache的具體技術細節上類似典型的KV存儲，就是將SELECT語句和該查詢語句的結果集做了一個HASH映射并保存在一定的內存區域中。當客戶端發起SQL查詢時，Query Cache的查找邏輯是，先對SQL進行相應的權限驗證，接著就通過Query Cache來查找結果（注意必須是完全相同，即使多一個空格或者大小寫不 同都認為不同，即使完全相同的SQL，如果使用不同的字符集、不同的協議等也會被認為是不同的查詢而分別進行緩存）。它不需要經過Optimizer模塊進行執行計劃的分析優化，更不需要發生同任何存儲引擎的交互，減少了大量的磁盤IO和CPU運 算，所以有時候效率非常高。

二、查詢緩存命中

判斷一個緩存是否被命中，通過查詢語句的HASH值來判斷，HASH值因素包括查詢語句、查詢數據庫、客戶端版本協議等，如查詢語句任何字符的不同，都會導致HASH結果的不同，都可能導致緩存無法命中。有些查詢不能被緩存，如查詢中包含UDF、存儲函數、用戶自定義變量、臨時表、mysql庫中系統表、或者包含列級權限的表、有著不確定值的函數(Now()); 查詢緩存是完全存儲在內存中的，對整個內存空間分配回收等，會額外產生系統資源消耗，這會導致內存碎片的產生。

三、查看查詢緩存的參數

MariaDB [(none)]> show global variables like '%query%';
+------------------------------+--------------------+
| Variable_name                | Value              |
+------------------------------+--------------------+
| expensive_subquery_limit     | 100                |
| ft_query_expansion_limit     | 20                 |
| have_query_cache             | YES                |
| long_query_time              | 10.000000          |
| query_alloc_block_size       | 16384              |
| query_cache_limit            | 1048576            |
| query_cache_min_res_unit     | 4096               |
| query_cache_size             | 16777216           |
| query_cache_strip_comments   | OFF                |
| query_cache_type             | ON                 |
| query_cache_wlock_invalidate | OFF                |
| query_prealloc_size          | 24576              |
| slow_query_log               | OFF                |
| slow_query_log_file          | localhost-slow.log |
+------------------------------+--------------------+
14 rows in set (0.01 sec)

查詢緩存相關變量說明

query_cache_min_res_unit: 查詢緩存中內存塊的最小分配單位；較小值會減少浪費，但會導致更頻繁的內存分配操作；較大值會帶來浪費，會導致碎片過多；

query_cache_limit：能夠緩存的最大查詢結果；對于有著較大結果的查詢語句，建議在SELECT中使用SQL_NO_CACHE

query_cache_size：查詢緩存總共可用的內存空間；單位是字節，必須是1024的整數倍；

query_cache_type: ON, OFF, DEMAND

  a、0(OFF)：關閉 Query Cache 功能，任何情況下都不會使用 Query Cache；

  b、1(ON)：開啟 Query Cache 功能，但是當SELECT語句中使用SQL_NO_CACHE提示后，將不使用Query Cache；

  c、2(DEMAND)：開啟Query Cache 功能，但是只有當SELECT語句中使用了SQL_CACHE 提示后，才使用Query Cache。

query_cache_wlock_invalidate：如果某表被其它的連接鎖定，是否仍然可以從查詢緩存中返回結果；默認值為OFF，表示可以在表被其它連接鎖定的場景中繼續從緩存返回數據；ON則表示不允許；

MariaDB [(none)]> show global status like 'Qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 1        |
| Qcache_free_memory      | 16759656 |
| Qcache_hits             | 0        |
| Qcache_inserts          | 0        |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 7        |
| Qcache_queries_in_cache | 0        |
| Qcache_total_blocks     | 1        |
+-------------------------+----------+
8 rows in set (0.00 sec)

查看緩存變量參數說明：

Qcache_free_blocks: 緩存池中空閑塊的個數，空閑的內存塊。

Qcache_free_memory: 緩存中空閑內存空間

Qcache_hits: 緩存命中次數

Qcache_inserts: 可緩存查詢語句的結果被放入緩存的次數

Qcache_lowmen_prunes: 有多少次是因為查詢緩存內存空間太少而使用LRU算法清理緩存的次數

Qcache_not_cached: 可緩存卻未能緩存的結果,例如查詢結果超出緩存塊大小,查詢中包含可變函數等

Qcache_queries_in_cache: 當前緩存中緩存的SQL數量

Qcache_total_blocks: 整個查詢緩存有多少內存塊

緩存命中率：Qcache_hits/(Qcache_hits+Com_select)

四、分析和配置查詢緩存流程及提高緩存命中率

①.開始，如果查詢緩存命中率是否可以接受？如果可以的話，就結束。

②.不能接受目前的緩存命中率，查看大部分查詢不是可緩存？是的話，就是大部分查詢都不能緩存，query_cache_limit足夠大嗎？如果是，就結束，說明查詢不能緩存，有可能是用戶自定義變量、存儲函數等，這種情況，建議關閉查詢緩存。如果不是足夠大，則需要增加此值。

③.1.大部分查詢緩存都是可以緩存，但是卻沒有被緩存。是否發生很多嚴重工作？

        是的話，查看緩存是不是被碎片化。需要降低query_cache_min_res_unit的值或是否flush query cache命令來整理緩存，減少碎片。

③.2.如果緩存不是因為碎片太多導致沒有被緩存，內存過低發生的修正工作？

④.1.如果是內存過低，則增加query_cache_size。

④.2.如果不是內存過低，是否有很多的更新語句？頻繁的更新表導致的緩存不能被命中，是有很多頻繁更新的語句，負載不適合緩存，建議關閉緩存。不是有很多頻繁更新的語句，則有其他配置的問題。

⑤.如果不是發生了很多驗證工作，緩存啟動了？是，沒有見過此查詢。否的話，啟動緩存。