MySQL 核心深度優化

作者介紹：簡懷兵，騰訊雲資料庫進階工程師，負責騰訊雲CDB核心及基礎設施建設；先後供職于Thomson Reuters和YY等公司，PTimeDB作者，曾獲一項發明專利；從事MySQL核心開發工作8年，具有豐富的優化經驗；在分布式存儲等領域有較豐富經驗。

MYSQL資料庫适用場景廣泛，相較于Oracle、DB2成本效益更高，Web網站、日志系統、資料倉庫等場景都有MYSQL用武之地，但是也存在對于事務性支援不太好（MySQL 5.5版本開始預設引擎才是InnoDB事務型）、存在多個分支、讀寫效率瓶頸等問題。

是以如何用好MYSQL變得至關重要，一方面需要通過MYSQL優化找出系統讀寫瓶頸，提高資料庫性能；另一方面需要合理涉及資料結構、調整參數，以提高使用者操作響應；同時還有盡可能節省系統資源，以便系統可以提供更大負荷的服務。本文将為大家介紹騰訊雲團隊是如何對Mysql進行核心級優化的思路和經驗。

早期的CDB主要基于開源的Oracle MySQL分支，側重于優化運維和營運的OSS系統。在騰訊雲，因為使用者數的不斷增加，對CDB for MySQL提出越來越高的要求，騰訊雲CDB團隊針對使用者的需求和業界發展的技術趨勢，對CDB for MySQL分支進行深度的定制優化。優化重點圍繞核心性能、核心功能和外圍OSS系統三個次元展開，具體的做法如下：

由于騰訊雲上的DB基本都需要跨園區災備的特性，是以CDB for MySQL的優化主要針對主從DB部署在跨園區網絡拓撲的前提下，重點去解決真實部署環境下的性能難題。經過分析和調研，我們将優化的思路歸納為：“消除備援I/O、縮短I/O路徑和避免大鎖競争”。以下是核心性能的部分案例：

如上圖所示，在原生MySQL的複制架構中，Master側通過Dump線程不斷發送Binlog事件給Slave的I/O線程，Slave的I/O線程在接受到Binlog事件後，有兩個主要的動作：

寫入到Relay Log中，這個過程會和Slave SQL線程争搶保護Relay Log的鎖。

更新複制中繼資料(包含Master的位置等資訊)。

經過分析，我們的優化政策是：

Slave I/O線程和Slave SQL線程是典型的單寫單讀生産者-消費者模型，是可以做到無鎖設計的；是以實作思路就是Slave I/O線程在每次寫完資料後，原子更新Relay Log的長度資訊，Slave SQL線程讀取Relay Log的時以長度資訊為邊界。這樣就将原本競争激烈的Relay Log鎖化解為無鎖；

由于Binlog事件中的GTID(Global Transaction Identifier)和DB事務是一一對應的關系，是以Relay Log中的資料本身已經包含了所需要的複制中繼資料，是以我們可以不寫Master info檔案，消除了備援的檔案I/O；

于DB都是以事務為更新粒度的，因為在Relay Log檔案I/O上，我們通過合并離散小I/O為事務粒度的大I/O等手段，使磁盤I/O得以大幅提升。

如上圖所示，經過優化：左圖35.79%的鎖競争(futex)已經被完全消除；同壓測壓力下，56.15%的檔案I/O開銷被優化到19.16%，Slave I/O線程被優化為預期的I/O密集型線程。

如上圖所示，在原生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%左右。

在騰訊雲上，不時遇到使用者APP異常或者BUG進而占滿DB的最大連接配接限制，這是CDB OSS帳号無法登入以進行緊急的運維操作。針對這個現狀，我們在MySQL核心單獨開辟了一個可配置的連接配接數配額，即便在上述場景下，運維帳号仍然可以連接配接到DB進行緊急的運維操作。極大地降低了異常情況下DB無政府狀态的風險。該帳号僅有資料庫運維管理權限，無法擷取使用者資料，也保證了使用者資料的安全性。

針對一些應用對資料的一緻性要求非常高，CDB在MySQL原生半同步的基礎上進行了深度優化，確定一個事務在主庫上送出之前一定已經複制到至少一個備庫上。確定主庫當機時資料的一緻性。

除了以上提到的MySQL核心側的部分優化，我們也在外圍OSS平台進行了多處優化。例如使用異步MySQL ping協定實作大量執行個體的監控、通過分布式技術來加強原有系統的HA/服務發現和自動擴容等功能、在資料安全/故障切換和快速恢複方面也進行了多處優化。