mysql 緩存機制

轉自：https://www.cnblogs.com/lpfut...

介紹

• mysql Query Cache 默認爲打開。從某種程度能夠提升查詢的效果，可是未必是最優的解決方案，若是有的大量的修改和查詢時，因爲修改造的cache失效，會給服務器形成很大的開銷，能夠經過query_cache_type【0(OFF)1(ON)2(DEMAND)】來控制緩存的開關.
• 須要注意的是mysql query cache 是對大小寫敏感的，由於Query Cache 在內存中是以 HASH 結構來進行映射，HASH 算法基礎就是組成 SQL 語句的字符，因此 任何sql語句的改變從新cache,這也是項目開發中要創建sql語句書寫規範的緣由吧

什麼時候cache

• mysql query cache內容爲 select 的結果集, cache 使用完整的 sql 字符串作 key, 並區分大小寫，空格等。即兩個sql必須徹底一致纔會致使cache命中。
• prepared statement永遠不會cache到結果，即便參數徹底同樣。在 5.1 以後會獲得改善。
• where條件中如包含了某些函數永遠不會被cache, 好比current_date, now等。

• date 之類的函數若是返回是以小時或天級別的，最好先算出來再傳進去。

  select * from foo where date1=current_date -- 不會被 cache
  select * from foo where date1='2008-12-30' -- 被cache, 正確的作法

• 太大的result set不會被cache (< query_cache_limit)

什麼時候更新

• 一旦表數據進行任何一行的修改，基於該表相關cache當即所有失效。
• 爲何不作聰明一點判斷修改的是否cache的內容？由於分析cache內容太複雜，服務器須要追求最大的性能。

性能

• ache 未必全部場合老是會改善性能

  • 當有大量的查詢和大量的修改時，cache機制可能會形成性能降低。由於每次修改會致使系統去作cache失效操做，形成不小開銷。
  • 另外系統cache的訪問由一個單一的全局鎖來控制，這時候大量>的查詢將被阻塞，直至鎖釋放。因此不要簡單認爲設置cache一定會帶來性能提高。

• 大result set不會被cache的開銷

  • 太大的result set不會被cache, 但mysql預先不知道result set的長度，因此只能等到reset set在cache添加到臨界值 query_cache_limit 以後纔會簡單的把這個cache 丟棄。這並非一個高效的操做。若是mysql status中Qcache_not_cached太大的話, 則可對潛在的大結果集的sql顯式添加 SQL_NO_CACHE 的控制。
  • query_cache_min_res_unit = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache

緩存機制的內存使用

• mysql query cache 使用內存池技術，本身管理內存釋放和分配，而不是經過操做系統。內存池使用的基本單位是變長的block, 一個result set的cache經過鏈表把這些block串起來。由於存放result set的時候並不知道這個resultset最終有多大。block最短長度爲query_cache_min_res_unit, resultset 的最後一個block會執行trim操做。

使用步驟

1. 修改配置文件，設置query_cache_type和query_cache _size，以及query_cache_min_res_unit（能夠採用默認值）

   query_cache_type 0 表明不使用緩衝， 1 表明使用緩衝，2 表明根據須要使用。

2. 若是query_cache_type=1，若是不須要緩衝，則query以下

   SELECT SQL_NO_CACHE * FROM my_table WHERE ...

3. 若是query_cache_type=2，若是須要緩衝，則query以下

   SELECT SQL_CACHE * FROM my_table WHERE ...

總結

• Query Cache 在提升數據庫性能方面具備很是重要的做用。
• 其設定也很是簡單，僅須要在配置文件寫入兩行： query_cache_type 和 query_cache _size，並且 MySQL 的 query cache 很是快！並且一旦命中，就直接發送給客戶端，節約大量的 CPU 時間。
• 固然，非 SELECT 語句對緩衝是有影響的，它們可能使緩衝中的數據過時。一個 UPDATE 語句引發的部分表修改，將致使對該表全部的緩衝數據失效，這是 MySQL 爲了平衡性能而沒有采起的措施。由於，若是每次 UPDATE 須要檢查修改的數據，而後撤出部分緩衝將致使代碼的複雜度增長。

• 使用場景

  • 寫操做少於讀操做；數據實時性要求較強（即不容許緩存中存在過時數據）
  • 若是容許緩存中存在過時數據，能夠本身使用Redis等工具進行緩存