阿裡雲關系型資料庫RDS（Relational Database Service） MySQL 是一種高效、穩定、安全可靠、可彈性伸縮的線上MySQL資料庫服務。為了提供極具競争力的MySQL服務，阿裡雲RDS MySQL在包括核心、管理系統上都有深度的技術加強和優化，本系列文章将會逐一對RDS MySQL特性進行拆解，主要從效能、穩定性、安全三個角度分享相比開源MySQL自建核心優勢。
本文重點介紹阿裡雲資料庫MySQL的核心查詢加速技術Fast Query Cache功能。
資料庫是企業的核心資産，尤其是基于網際網路業務的現代企業，較于傳統型企業，其系統的資料量和通路量都高出很多，并且存在突峰爆發的場景。資料庫的穩定表現往往直接關系的企業業務的連續性，甚至可能關系企業生死。
1. OLTP資料庫的請求特點和優化方案
大部分的業務資料庫系統都是線上事務性（OLTP）的，究其特點，一是單次操作資料庫的關系資料量很少，如幾條記錄或者幾十條記錄；二是對資料庫的讀請求量要遠高于寫請求量，即讀寫比嚴重不平衡，如電商業務訂單系統，一條訂單随業務推展而狀态改變約在10次，而對應的查詢次數要超過200次。是以OLTP類資料庫的資源主要消耗于對小資料量的查詢請求處理。
為了解決這種讀寫比傾斜嚴重的問題，一般會采取如下幾種方案：
方案一：擴容資料庫硬體，尤其是增加記憶體，我們稱之為 資料庫的Scale up的方案。對應MySQL增加Buffer Pool大小，可快速有效提升性能。
方案二：可稱之為資料庫的Scale out方案，增加資料庫讀副本，MySQL相對比較容易做到，通過建立多個隻讀備庫可極大的擴充資料庫的讀請求處理能力。但本方案帶來一個問題，就是應用要實作對讀寫請求的路由識别，隻将讀請求（非事務内）路由到隻讀庫，否則大量寫請求路由到隻讀庫後業務将會出現大量失敗，“不小心”還會導緻資料寫入錯誤。另外，應用還需要關注隻讀庫與源庫的資料延遲時間，時間太長一般業務都難以接受，經驗來看秒級延遲是基本要求。
方案三：對業務系統進行架構改造，做大量的解耦工作，針對核心表做成中心服務化形式對外提供服務，如阿裡淘寶天貓的幾大C系統模式。該方案的核心就是引入緩存系統，一般開源如Redis系統，利用緩存承接大量的讀請求，但整體系統需要考慮緩存失效的問題，同時還要分别維護緩存和資料庫兩套系統，技術研發成本較高。
2. 開源MySQL的Query Cache方案和問題
從上述三種方案比較來看，方案三增加查詢結果集緩存是對資料庫非常理想的解決方案，這也是大型網際網路公司普遍采用的方案，但此方案畢竟要涉及不少的應用系統改造，工程量較大，故MySQL引入了一種查詢緩存技術（Query Cache）。
MySQL Query Cache的執行流程圖如下，其儲存查詢傳回的完整結果，當新查詢命中該緩存會立刻傳回結果，跳過了SQL解析、優化和執行等複雜階段。同時Query Cache會跟蹤查詢中涉及的每個表，如果這些表發生變化，那麼和這個表相關的所有緩存都将失效。
MySQL Query Cache原理上是通過使用額外記憶體來節約CPU資源來達到查詢加速的目标，是一項非常實用的技術，與MySQL組合Redis方案相比，具有以下幾個優勢：
- 應用透明，使用Query Cache可以不更改用戶端應用程式，隻需要在Server端進行簡單配置，而使用Redis則需要更改用戶端應用程式。
- 資料一緻，使用Query Cache無資料同步問題，并且可以保證事務級一緻性，而使用Redis則涉及資料同步，無法實作事務級一緻性。
- 成熟穩定，MySQL有成熟的事務引擎及複制技術，可以保證資料不丢失，而Redis的持久化及複制技術不夠成熟，使用Redis需要考慮到資料丢失的問題。
但開源MySQL 實作的Query Cache不夠優雅，實際應用中存在不少問題：
- 并發處理不夠好，在多核情況下，可能并發越高性能退化越嚴重。
- 當緩存命中率較低時，性能無提升甚至會出現嚴重退化。
- 記憶體管理問題，記憶體使用率低并且回收不及時，造成記憶體浪費。
- 當向某個表寫入資料的時候，必須将這個表所有的緩存設定為失效，如果緩存空間很大，則消耗也會很大，可能使系統僵死一段時間，因為這個操作是靠全局鎖操作來保護的。
3. 阿裡雲資料庫MySQL的Fast Query Cache
阿裡雲資料庫MySQL針對開源MySQL問題，通過對Query Cache重新設計，實作了一種更好的查詢緩存機制，稱為Fast Query Cache，解決了以上幾個主要問題：
-
優化并發控制：
取消全局鎖同步機制，并采用無鎖機制，重新設計并發場景下的同步問題，能夠充分利用多核的處理能力，保證高并發場景下的性能。
-
優化緩存機制：
動态檢測緩存使用率，實時調整緩存政策，解決命中率偏低或讀寫混合等場景下的性能退化問題。
- 優化記憶體管理：取消記憶體預配置設定機制，采用更加靈活的動态記憶體配置設定機制，無效的記憶體及時回收，保證記憶體的真實使用率。
阿裡雲資料庫MySQL Fast Query Cache 開啟方法和開源Query Cache完全一緻，通過query_cache_type參數設定為“ON”打開。在實際測試中，采用4核8GB記憶體的機器，利用sysbench壓測，總共資料量有250MB（25張表，每張表40000條記錄），效果非常好。
1) 全部命中隻讀場景
Sysbench oltp_point_select，用例中僅包括主鍵上的點查（point select），将Query Cache設為512MB，記憶體大于測試資料量，緩存命中率達到99%以上。
測試結果顯示，在較高并發的場景下，MySQL原生Query Cache并發處理性能出現較大幅度的降低，Fast Query Cache在各個并發場景下無性能降低，最高時能夠提高一倍的QPS。
2) 高命中率隻讀場景
Sysbench oltp_read_only，用例中包含傳回多條記錄的範圍查詢，将Query Cache設為512MB，記憶體才相對比較充足，命中率可以達到80%以上。
測試結果顯示，随着并發數的增加，MySQL原生Query Cache的性能出現明顯的降低，Fast Query Cache的性能則會不斷提升，最高時能夠提高一倍多的QPS。
3) 低命中率隻讀場景
Sysbench oltp_read_only，用例中包含傳回多條記錄的範圍查詢，将Query Cache設為16MB，記憶體明顯嚴重不足，緩存命中率隻有10%左右，記憶體不足時會涉及緩存項的大量淘汰，影響性能。
測試結果顯示，MySQL原生Query Cache的性能降低明顯，最多出現了接近50%的性能損失，Fast Query Cache優化了低命中率場景，将性能損失控制在2%以内。
4) 讀寫混合場景
Sysbench oltp_read_write，每個事務中都有對表的更新操作，可以認為緩存基本處于失效狀态，頻繁的更新操作涉及緩存的主動淘汰，理論上會比較影響性能。
測試結果顯示，Fast Query Cache在讀寫混合場景下不會出現過多的性能降低，整體性能影響控制在2%以内。
4. 總結
最後，阿裡雲資料庫MySQL Fast Query Cache大大增強了資料庫查詢性能，通過增加一點點的記憶體換取巨大的性能提升，在主要業務場景（讀場景）中性能提升達到1倍，将會取得巨大的收益，在使用方式上和開源MySQL Query Cache保持完全一緻，具備領先業界的産品競争力。
目前Fast Query Cache已經在RDS 和 雲專屬叢集RDS中具備。雲資料庫專屬叢集RDS，使用者100%獨占底層實體機，且支援使用者通過彈性資源功能靈活調配資料庫執行個體資源占用，這樣開啟Fast Query Cache将會再獲得一倍性能收益，結合CPU超配技術最少獲得的一倍收益，則相比于在實體機自建，專屬叢集整體成本可達到後者約30%，是目前雲上企業最好的資料庫節省成本方案。