針對原生MySQL Query Cache的不足，阿里云進行重新設計和全新實現，推出Fast Query Cache，能夠有效提高數據庫查詢性能。
前提條件
- 實例版本為MySQL 5.7（內核小版本20200331或以上）。
- 實例未開啟數據庫獨享代理。
背景信息
查詢緩存（Query Cache）是為了提高查詢性能而實現的一種緩存策略，其基本思想是：對于每個符合條件的查詢語句，直接對結果集進行緩存，當下次查詢命中時，直接從緩存中取出對應的結果集返回，不需要經歷SQL的分析、優化、執行等復雜過程，通過節約CPU資源來達到查詢加速的目標，是一項非常實用的技術。
MySQL原生Query Cache在設計和實現上存在著較多嚴重問題：
- 并發處理較差，在多核情況下，可能并發越高性能降低越嚴重。
- 內存管理較差，內存利用率低并且回收不及時，造成內存浪費。
- 當緩存命中率較低時，性能無提升甚至會出現嚴重降低。
由于以上問題，MySQL原生Query Cache沒有得到廣泛應用，在最新版的MySQL 8.0中，取消此功能。阿里云數據庫團隊對Query Cache進行重新設計和全新實現，解決了以上幾個主要問題：
- 優化并發控制
取消全局鎖同步機制，采用無鎖機制，重新設計并發場景下的同步問題，能夠充分利用多核的處理能力，保證高并發場景下的性能。
- 優化內存管理
取消內存預分配機制，采用更加靈活的動態內存分配機制，及時回收無效的內存，保證內存的真實利用率。
- 優化緩存機制
動態檢測緩存利用率，實時調整緩存策略，解決命中率偏低或讀寫混合等場景下的性能降低問題。
相比原生Query Cache，Fast Query Cache可以在不同的業務場景中放心開啟，提高查詢性能。
使用Fast Query Cache
您可以在RDS控制臺設置參數query_cache_type和query_cache_size使用Fast Query Cache。
| 參數 | 說明 |
|---|---|
| query_cache_type | Fast Query Cache功能開關，取值：
|
| query_cache_size | Fast Query Cache使用的內存大小，取值范圍：0~10485760000，需要為1024的整數倍。單位：Byte。 |
由于Fast Query Cache功能需要占用額外的內存空間，所以建議使用Fast Query Cache功能時同步修改參數innodb_buffer_pool_size的大小，推薦的修改步驟如下：
- 修改innodb_buffer_pool_size為原先的90%，分出10%的空間給query_cache_size。例如原先為{DBInstanceClassMemory*7/10}，需要改為{DBInstanceClassMemory*63/100}。具體操作，請參見調整實例Buffer Pool大小。
- 修改參數query_cache_size。具體操作，請參見設置實例參數。
- 若能夠評估結果集大小，query_cache_size可以設置為
20% * 結果集大小。 - 若無法準確評估結果集大小，query_cache_size可以設置為
10% * innodb_buffer_pool_size。
說明 如果變更實例規格，參數query_cache_size的值不會隨實例規格變化，請及時修改此參數值。 - 若能夠評估結果集大小，query_cache_size可以設置為
- 修改參數query_cache_type為1，開啟Fast Query Cache功能。具體操作，請參見設置實例參數。
性能比較
在相同場景下，分別測試QC-OFF（關閉Query Cache）、MySQL-QC（開啟MySQL原生Query Cache）和Fast-QC（開啟Fast Query Cache）的QPS。
- 測試環境：4核8GB 獨享型實例
- 測試工具：Sysbench
- 數據量：250MB（25張表，每張表40000條記錄）
- 場景1：全部命中（只讀）
測試場景為Sysbench oltp_point_select，用例中僅包括主鍵上的點查（point select），將Query Cache設為512MB，內存大于測試數據量，緩存可以全部命中，主要關注不同并發下的性能提升效果。
表 1. 全部命中（只讀）QPS 并發數 QC-OFF MySQL-QC（相比QC-OFF提升） Fast-QC（相比QC-OFF提升） 1 8093 8771（8.38%） 9261（14.43%） 8 62262 65686（5.50%） 75313（20.96%） 16 97083 73027（-24.78%） 139323（43.51%） 32 97337 60567（-37.78%） 200978（106.48%） 64 106283 60216（-43.34%） 221659（108.56%） 128 107781 62844（-41.69%） 231409（114.70%） 256 106694 63832（-40.17%） 222187（108.25%） 512 101733 64866（-36.24%） 203789（100.32%） 1024 89548 62291（-30.44%） 203542（127.30%） 
說明 測試結果顯示，在較高并發的場景下，MySQL原生Query Cache并發處理性能出現較大幅度的降低，Fast Query Cache在各個并發場景下無性能降低，最高時能夠提高一倍的QPS。 - 場景2：高命中率（只讀）
測試場景為Sysbench oltp_read_only，用例中包含返回多條記錄的范圍查詢，將Query Cache設為512MB，內存才相對比較充足，命中率可以達到80%以上，這時主要關注不同并發下的性能提升效果。
表 2. 高命中率（只讀）QPS 并發數 QC-OFF MySQL-QC（相比QC-OFF提升） Fast-QC（相比QC-OFF提升） 1 5099 6467（26.83%） 7022（37.71%） 8 28782 28651（-0.46%） 45017（56.41%） 16 35333 31099（-11.98%） 66770（88.97%） 32 34864 27610（-20.81%） 67623（93.96%） 64 35503 27518（-22.49%） 75981（114.01%） 128 35744 27733（-22.41%） 80396（124.92%） 256 35685 27738（-22.27%） 80925（126.78%） 512 35308 27398（-22.40%） 79323（124.66%） 1024 34044 26861（-22.10%） 75742（122.48%） 
說明 測試結果顯示，隨著并發數的增加，MySQL原生Query Cache的性能出現明顯的降低，Fast Query Cache的性能則會不斷提升，最高時能夠提高一倍多的QPS。 - 場景3：低命中率（只讀）
測試場景為Sysbench oltp_read_only，用例中包含返回多條記錄的范圍查詢，將Query Cache設為16MB，內存明顯嚴重不足，緩存命中率只有10%左右，內存不足時會涉及緩存項的大量淘汰，影響性能，這時主要關注不同并發下的性能降低程度。
表 3. 低命中率（只讀）QPS 并發數 QC-OFF MySQL-QC（相比QC-OFF提升） Fast-QC（相比QC-OFF提升） 1 5004 4727（-5.54%） 5199（3.90%） 8 28795 22542（-21.72%） 28578（-0.75%） 16 35455 24064（-32.13%） 35682（0.64%） 32 34526 21330（-38.22%） 35871（3.90%） 64 35514 19791（-44.27%） 36051（1.51%） 128 35983 19519（-45.75%） 36253（0.75%） 256 35695 19168（-46.30%） 36337（1.80%） 512 35182 18420（-47.64%） 35972（2.25%） 1024 33915 20168（-40.53%） 34546（1.86%） 
說明 測試結果顯示，MySQL原生Query Cache的性能降低明顯，最多出現了接近50%的性能損失，Fast Query Cache優化了低命中率場景，幾乎不會帶來任何額外的性能損失。 - 場景4：讀寫混合
測試場景為Sysbench oltp_read_write，每個事務中都有對表的更新操作，可以認為緩存基本處于失效狀態，頻繁的更新操作涉及緩存的主動淘汰，理論上會比較影響性能，這時主要關注不同并發下的性能衰減程度。
表 4. 讀寫混合QPS 并發數 QC-OFF Fast-QC（相比QC-OFF提升） 1 4152 4098（-1.30%） 8 21359 21195（-0.77%） 16 26020 25548（-1.81%） 32 27595 26996（-2.17%） 64 29229 28733（-1.70%） 128 29265 28828（-1.49%） 256 29911 29616（-0.99%） 512 29148 28816（-1.14%） 1024 29204 28824（-1.30%） 
說明 測試結果顯示，Fast Query Cache在讀寫混合場景下不會出現過多的性能降低，整體性能影響很小。
實踐指南
在緩存數據集大小明確的情況下，例如使用SQL_CACHE關鍵字對指定表開啟Query Cache，可以參照前面的測試進行性能評估。接下來將對Fast Query Cache的使用作一些補充說明。
- 適用場景指南
- Fast Query Cache主要目的是提高讀操作性能，建議在讀多寫少的場景下開啟，或者使用SQL_CACHE關鍵字針對讀多寫少的表開啟。如果寫多讀少，數據的更新非常頻繁，可能會出現很少的性能降低。
- 開啟Fast Query Cache帶來的性能提升和緩存命中率直接相關。在全局開啟前建議查看InnoDB Buffer Pool的命中率（命中率 = 1 - Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests），如果命中率低于80%，則不建議開啟。您也可以通過TABLE_STATISTICS表查看表級別的讀寫比，對讀寫比高的表通過SQL_CACHE關鍵字顯式開啟Fast Query Cache。查詢TABLE_STATISTICS表請參見Performance Insight。
- 緩存使用方式（query_cache_type）
query_cache_type參數支持會話級修改，用戶可以根據真實業務場景進行靈活設置，請參見以下建議：
- 對于更新頻繁、寫多讀少等不適合Query Cache的場景，應將query_cache_type全局設置為0。
- 對于數據量較小、訪問模式比較固定、命中率較高的場景，可以將query_cache_type全局設置為1。
- 對于數據量較大、訪問模式不固定、命中率無法保障的場景，可將query_cache_type設置為2，僅對指定的語句，通過SQL_CACHE關鍵字使用Fast Query Cache。
- 緩存大小（query_cache_size）設置
query_cache_size和SQL息息相關，如果緩存中有返回多條記錄的查詢，緩存可能需要是數據量的數倍。如果SQL中不包含范圍查詢，可以參見以下測試來評估數據量和query_cache_size的關系。
- 測試環境：4核8GB獨享型實例（innodb_buffer_pool_size=6GB）
- 測試工具：Sysbench
- 數據量：10GB（100張表，每張表400000條記錄）
測試場景為Sysbench oltp_point_select、64并發、Special分布（20%熱點）。測試不同query_cache_size大小對于性能的影響。對應上述的數據量，全量結果集的真實大小為2.5GB。
表 5. 不同緩存QPS query_cache_size（MB） QC-OFF Fast-QC命中率 Fast-QC（相比QC-OFF提升） 64 98236 22% 99440（1.23%） 128 98236 45% 114155（16.21%） 256 98236 72% 140668（43.19%） 512 98236 82% 151260（53.98%） 1024 98236 84% 153866（56.63%） 2048 98236 87% 159597（62.46%） 4096 98236 92% 169412（72.45%） Fast Query Cache在不同query_cache_size的設置下都不會引起性能退化，對于主鍵查詢操作，在不同緩存命中率下都有性能提升，達到90%以上時，提升效果比較明顯；對于范圍查詢或帶
Order By的排序語句，緩存命中率低于90%時，也能節約大量的CPU，帶來較大的性能提升。