今天線上MySQL 出現記憶體使用率警報，就去查了下mysql記憶體使用的參數，重點是緩存，關於innodb_buffer_pool_size以及query cache的使用。
query_cache_type 預設是開啟的，而且快取區query_cache_size預設大小是32M，通常建議不超過256M大小，可以用查詢cache參數來看特定值：
「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
Query Cache 命中率= Qcache_hitsQuery Cache 命中率= Qcache_hits
Query Cache 命中率= Qcache_hits ● 「Qcache_lowmem_prunes」：多少條Query 因為記憶體不足而被清除出Query Cache。透過
「Qcache_lowmem_prunes」和「Qcache_free_memory」相互結合，更清楚的了解到我們係
統中Query Cache 的記憶體大小是否真的足夠，是否非常頻繁的出現因為記憶體不足而有Query Cache 的記憶體大小是否真的足夠，是否非常頻繁的出現因為記憶體不足而有Query Cache 的記憶體大小是否真的足夠，是否非常頻繁的出現因為記憶體不足而有Query Cache 的記憶體大小是否真的夠
出
● 「Qcache_not_cached」：因為query_cache_type 的設定或不能被cache 的Query 的數量；
ache_acheSachecache_acheSache的數量：
● 「Qcache_total_blocks」：目前Query Cache 中的block 數量；
Query Cache 的限制
Query Cache 由於存放的都是邏輯結構的Result 也會受到一些特定的限制。 a) 5.1.17 之前的版本不能Cache 幫定變數的Query，但是從5.1.17 版本開始，Query Cache 已經
開始支援所有查詢的Query 了；
外部查詢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
SQL Query Cache的一些交流心得的內容，更多相關內容請關注PHP中文網（m.sbmmt.com）！
