PolarDB：Fast Query Cache

使用限制

問題與最佳化

查詢快取（Query Cache）是為了提高查詢效能而實現的一種緩衝策略，它通過節約CPU資源來達到查詢加速的目標，是一項非常實用的技術。其基本思想是：對於每個合格查詢語句，直接對結果集進行緩衝。當該結果集被重新查詢命中時，直接從緩衝中讀取對應的結果集並返回，不需要經歷SQL的分析、最佳化、執行等複雜的過程。

MySQL原生Query Cache在設計和實現上存在較多的嚴重問題，具體如下：

• 並發處理較差，在多核情況下，並發度越高效能降低可能越嚴重。

• 記憶體管理較差，記憶體利用率低且回收不及時，造成記憶體浪費。

• 當快取命中率較低時，效能無提升甚至嚴重降低。

基於以上問題，MySQL原生Query Cache沒有得到廣泛應用，在最新版的MySQL 8.0中，取消了此功能。PolarDB對Query Cache進行重新設計和全新實現，進行了如下最佳化：

• 最佳化並發控制

  取消全域鎖同步機制，採用無鎖機制，重新設計並發情境下的同步問題，能夠充分利用多核的處理能力，保證高並發情境下的效能。

• 最佳化記憶體管理

  取消記憶體預分配機制，採用更加靈活的動態記憶體分配機制，及時回收無效的記憶體，保證記憶體的真實利用率。

• 最佳化緩衝機制

  動態檢測緩衝利用率，即時調整緩衝策略，解決命中率偏低或讀寫混合等情境下的效能降低問題。

相比MySQL原生Query Cache，您可以在不同的業務情境中開啟Fast Query Cache以提高查詢效能。

開啟Fast Query Cache

效能比較

在相同情境下，分別測試QC-OFF（關閉Query Cache）和PolarDB-QC（開啟Fast Query Cache）的QPS。

• 測試環境

  • 一個規格為8核64 GB的PolarDB MySQL版8.0叢集版。

  • Query Cache記憶體為4 GB。

• 測試載入器

  Sysbench

• 測試資料量

  • 25張表，每張表4萬條記錄。

  • 25張表，每張表40萬條記錄。

• 測試案例

  使用以下Sysbench內建用例，分別在rand-type=special和uniform條件下進行測試。

  • oltp_read_only

  • oltp_point_select

  • oltp_read_write

• 測試結果及說明

  從以下測試中可以看到，Fast Query Cache在高並發情境較高命中率下效能提升非常明顯。在Case1、Case3、Case4、Case5、Case7等情境中，使用了Fast Query Cache後的快取命中率範圍在63%~99%之間，最大QPS提升範圍在53%~106%之間。Fast Query Cache的記憶體利用率很高，Case7在巨量資料量的point select情境中，其命中率依然達到了99%，效能提升較明顯。同時在低命中率情境下，Case2和Case6中的Fast Query Cache對並發效能的影響很小，基本在3%以內。對於高並發讀寫混合情境，效能影響也在2%以內。

  說明

  本文測試情境中的所有測試資料僅針對測試叢集中的主節點。

  • Case1：25 x 40k （tables x rows），rand-type = special oltp_read_only

  • Case2：25 x 40k （tables x rows），rand-type = uniform oltp_read_only

  • Case3：25 x 40k （tables x rows），rand-type = special oltp_point_select

  • Case4：25 x 40k （tables x rows），rand-type = uniform oltp_point_select

  • Case5：25 x 400k （tables x rows），rand-type = special oltp_read_only

  • Case6：25 x 400k （tables x rows），rand-type = uniform oltp_read_only

  • Case7：25 x 400k （tables x rows），rand-type = special oltp_point_select

  • Case8：25 x 400k （tables x rows），rand-type = uniform oltp_point_select

  • Case9：25 x 400k （tables x rows）， rand-type = special oltp_read_write

實踐指南

• 適用情境指南

  • Fast Query Cache主要作用是提高讀操作效能，建議在讀多寫少的情境下開啟，或者使用SQL_CACHE關鍵字針對讀多寫少的表開啟。如果寫多讀少，資料的更新非常頻繁，查詢效能可能會降低2%左右。

  • Fast Query Cache記憶體利用率很高，適用於更新很少但訪問量很大的點查情境中，大幅提升並發訪問效能。

• 緩衝使用方式（loose_query_cache_type）

  Fast Query Cache完全相容原生Query Cache的使用方法，可通過loose_query_cache_type參數控制緩衝。

  參數名	取值	說明
  loose_query_cache_type	OFF（預設值）	禁用Fast Query Cache。
  	ON	預設在查詢中使用Fast Query Cache功能，但可通過SQL_NO_CACHE關鍵字跳過緩衝。
  	DEMAND	預設在查詢中不使用Fast Query Cache功能，但可通過SQL_CACHE關鍵字對特定語句使用緩衝。

  說明

  loose_query_cache_type參數支援會話級修改，您可以參考如下建議並根據真實業務情境進行靈活設定：

  • 對於更新頻繁、寫多讀少等不適合Query Cache的情境，應將loose_query_cache_type全域設定為OFF。

  • 對於較多重複查詢、快取命中率較高或者較多重複的慢查詢情境，可以將loose_query_cache_type全域設定為ON。

  • 對於僅存在少量重複查詢的情境，可以將loose_query_cache_type設定為DEMAND，僅對指定的語句，通過SQL_CACHE關鍵字使用Fast Query Cache。樣本如下：

    SELECT SQL_CACHE id, name FROM customer;

• 緩衝租約時間 (query_cache_lease_time)

  Fast Query Cache會動態回收查詢快取的記憶體，降低記憶體的使用量。對於未失效的查詢快取，若在query_cache_lease_time時間（單位為秒）內沒有被任何查詢命中，則會在超過緩衝租約時間後被釋放，所對應的記憶體將被回收。該參數預設值為3600秒，即1小時。

相容性說明

Fast Query Cache功能與全域一致性（高效能模式）功能相容。若此前全域一致性（高效能模式）開啟了MTT最佳化功能，當同時開啟Fast Query Cache功能和全域一致性（高效能模式）功能時，全域一致性（高效能模式）的MTT最佳化功能將失效。全域一致性（高效能模式）功能詳情請參見概述。