MYSQL數據庫適用場景廣泛，相較於Oracle、DB2性價比更高，Web網站、日誌系統、數據倉庫等場景都有MYSQL用武之地，但是也存在對於事務性支持不太好（MySQL 5.5版本開始默認引擎纔是InnoDB事務型）、存在多個分支、讀寫效率瓶頸等問題。
一.內核性能的優化
由於騰訊雲上的DB基本都需要跨園區災備的特性，因此CDB for MySQL的優化主要針對主從DB部署在跨園區網絡拓撲的前提下，重點去解決真實部署環境下的性能難題。經過分析和調研，我們將優化的思路歸納爲：“消除冗餘I/O、縮短I/O路徑和避免大鎖競爭”。以下是內核性能的部分案例：
1.主備DB間的複製優化
問題分析
如上圖所示，在原生MySQL的複製架構中，Master側通過Dump線程不斷髮送Binlog事件給Slave的I/O線程，Slave的I/O線程在接受到Binlog事件後，有兩個主要的動作：
- 寫入到Relay Log中，這個過程會和Slave SQL線程爭搶保護Relay Log的鎖。
- 更新複製元數據(包含Master的位置等信息)。
優化方法
經過分析，我們的優化策略是：
優化效果
如上圖所示，經過優化：左圖35.79%的鎖競爭(futex)已經被完全消除；同壓測壓力下，56.15%的文件I/O開銷被優化到19.16%，Slave I/O線程被優化爲預期的I/O密集型線程。
2.主庫事務線程和Dump線程間的優化
問題分析
如上圖所示，在原生MySQL中多個事務提交線程TrxN和多個Dump線程之間會同時競爭Binlog文件資源的保護鎖，多個事務提交線程對Binlog執行寫入，多個Dump線程從Binlog文件讀取數據併發送給Slave。所有的線程之間是串行執行的！
優化方法
經過分析，我們的優化策略是：
- 將讀寫分離開來，多個寫入的線程還是在鎖保護下串行執行，每一個寫入線程寫入完成後更新當前Binlog的長度信息，多個Dump線程以Binlog文件的長度信息爲讀取邊界，多個Dump線程之間並行執行。以這種方式來讓複製拓撲中的Dump線程發送得更快！
效果
經過測試，優化後的內核，不僅提升了事務提交線程的性能，在Dump線程較多的情況下，對主從複製性能有較大提升。
二.主備庫交互流程優化
問題分析
如上圖所示，在原生MySQL中主備庫之間的數據發送和ACK迴應是簡單的串行執行，在上一個事件ACK迴應到達之前，不允許繼續發送下一個事件；這個行爲在跨園區(RTT 2-3ms)的情況性能非常差，而且也不能很好地利用帶寬優勢。
優化方法
經過分析，我們的優化策略是：
- 將發送和ACK迴應的接收獨立到不同的線程中，由於發送和接收都是基於TCP流的傳輸，所以時序性是有保障的；這樣發送線程可以在未收ACK之前繼續發送，接受線程收到ACK後喚醒等待的線程執行相應的任務。
效果
根據實際用例測試，優化後的TPS提升爲15%左右。
三.內核功能的優化
1. 預留運維帳號連接數配額
2. 主備強同步
針對一些應用對數據的一致性要求非常高，CDB在MySQL原生半同步的基礎上進行了深度優化，確保一個事務在主庫上提交之前一定已經複製到至少一個備庫上。確保主庫宕機時數據的一致性。
四.外圍系統的優化
除了以上提到的MySQL內核側的部分優化，我們也在外圍OSS平臺進行了多處優化。例如使用異步MySQL ping協議實現大量實例的監控、通過分佈式技術來加固原有系統的HA/服務發現和自動擴容等功能、在數據安全/故障切換和快速恢復方面也進行了多處優化。
