MySQL 核心深度優化

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/服務發現和自動擴容等功能、在資料安全/故障切換和快速恢復方面也進行了多處優化。

公眾號推薦：