今天線上MySQL 出現記憶體使用率報警，就去查了下mysql記憶體使用的引數，重點是快取，關於innodb_buffer_pool_size以及query cache的使用。

query_cache_type 預設是開啟的，而且快取區query_cache_size預設大小是32M，通常建議不超過256M大小，可以用過查詢cache引數來看具體值：

	
			mysql> show variables like '%cache%';  
		
			+------------------------------+----------------------+  
		
			| Variable_name                | Value                |  
		
			+------------------------------+----------------------+  
		
			| binlog_cache_size            | 32768                |  
		
			| binlog_stmt_cache_size       | 32768                |  
		
			| have_query_cache             | YES                  |  
		
			| key_cache_age_threshold      | 300                  |  
		
			| key_cache_block_size         | 1024                 |  
		
			| key_cache_division_limit     | 100                  |  
		
			| max_binlog_cache_size        | 18446744073709547520 |  
		
			| max_binlog_stmt_cache_size   | 18446744073709547520 |  
		
			| metadata_locks_cache_size    | 1024                 |  
		
			| query_cache_limit            | 1048576              |  
		
			| query_cache_min_res_unit     | 4096                 |  
		
			| query_cache_size             | 33554432             |  
		
			| query_cache_type             | ON                   |  
		
			| query_cache_wlock_invalidate | OFF                  |  
		
			| stored_program_cache         | 256                  |  
		
			| table_definition_cache       | 400                  |  
		
			| table_open_cache             | 512                  |  
		
			| thread_cache_size            | 8                    |  
		
			+------------------------------+----------------------+  
		
			18 rows in set (0.00 sec)  
		
			mysql>

“Qcache_free_blocks”：Query Cache 中目前還有多少剩餘的blocks。如果該值顯示較大，
則說明Query Cache 中的記憶體碎片較多了，可能需要尋找合適的機會進行整理（）。
● “Qcache_free_memory”：Query Cache 中目前剩餘的記憶體大小。透過這個引數我們可以較為準
確的觀察出當前系統中的Query Cache 記憶體大小是否足夠，是需要增加還是過多了；
● “Qcache_hits”：多少次命中。透過這個引數我們可以檢視到Query Cache 的基本效果；
● “Qcache_inserts”：多少次未命中然後插入。透過“Qcache_hits”和“Qcache_inserts”兩
個引數我們就可以算出Query Cache 的命中率了：
Query Cache 命中率= Qcache_hits / ( Qcache_hits + Qcache_inserts )；
● “Qcache_lowmem_prunes”：多少條Query 因為記憶體不足而被清除出Query Cache。透過
“Qcache_lowmem_prunes”和“Qcache_free_memory”相互結合，能夠更清楚的瞭解到我們系
統中Query Cache 的記憶體大小是否真的足夠，是否非常頻繁的出現因為記憶體不足而有Query 被換
出
● “Qcache_not_cached”：因為query_cache_type 的設定或者不能被cache 的Query 的數量；
● “Qcache_queries_in_cache”：當前Query Cache 中cache 的Query 數量；
● “Qcache_total_blocks”：當前Query Cache 中的block 數量；

Query Cache 的限制
Query Cache 由於存放的都是邏輯結構的Result Set，而不是物理的資料頁，所以在效能提升的同
時，也會受到一些特定的限制。
a) 5.1.17 之前的版本不能Cache 幫定變數的Query，但是從5.1.17 版本開始，Query Cache 已經
開始支援幫定變數的Query 了；
b) 所有子查詢中的外部查詢SQL 不能被Cache；
c) 在Procedure，Function 以及Trigger 中的Query 不能被Cache；
d) 包含其他很多每次執行可能得到不一樣結果的函式的Query 不能被Cache。
鑑於上面的這些限制，在使用Query Cache 的過程中，建議透過精確設定的方式來使用，僅僅讓合
適的表的資料可以進入Query Cache，僅僅讓某些Query 的查詢結果被Cache。

另外，如果Qcache_free_blocks值有點偏高,可以用flush query cache 來清理下。

一個朋友的建議：

第一個：讀操作多的話看看比例，簡單來說，如果是使用者清單表，或者說是資料比例比較固定，比如說商品列表，是可以開啟的，前提是這些庫比較集中，資料庫中的實務比較小。

第二個：我們“行騙”的時候，比如說我們競標的時候壓測，把query cache開啟，還是能收到qps激增的效果，當然前提示前端的連線池什麼的都配置一樣。大部分情況下如果寫入的居多，訪問量並不多，那麼就不要開啟，例如社交網站的，10%的人產生內容，其餘的90%都在消費，開啟還是效果很好的，但是你如果是qq訊息，或者聊天，那就很要命。

第三個：小網站或者沒有高併發的無所謂，高併發下，會看到很多 qcache 鎖等待，所以一般高併發下，不建議開啟query cache

MySQL Query Cache

相關文章