前提條件

• 實例版本為MySQL 8.0。

• 內核小版本：20230930或以上

  說明

  您可以在基本信息頁面的配置信息區域查看是否有升級內核小版本按鈕。如果有按鈕，您可以單擊按鈕查看當前版本；如果沒有按鈕，表示已經是最新版。詳情請參見升級內核小版本。

• 實例的sync_binlog參數不為1。

背景信息

在MySQL中，每個事務在提交階段都要寫Binlog。這個過程是串行的，即一個事務寫完后，另一個事務才能開始寫Binlog，如上圖所示。

同時，這個過程又是很耗時的，寫Binlog之前要將Binlog Cache中存儲的所有event都解析出來，填上Checksum和log_pos，還需要生成GTID event，隨后才能將這些event寫入Binlog文件。這個串行且耗時的過程，對實例的寫性能造成了很大的瓶頸。為了解決這個瓶頸，AliSQL引入了Binlog Parallel Flush優化。

優化詳情

Binlog Buffer

AliSQL在原有邏輯之上，引入了一個Binlog Buffer。多個線程在分配好位置之后，可以并行的將Binlog event寫到Binlog Buffer中，然后由后臺線程將Binlog Buffer寫入Binlog文件。這樣一來，原本串行的解析，填充Checksum和log_pos，生成GTID event等步驟，都可以并行的執行，極大優化了事務寫 Binlog的性能瓶頸。

并行組提交

在MySQL中，提交階段事務會成組地寫Binlog和Redo Log，這樣做可以最大限度地合并IO操作，提升性能。在本優化中，依舊保留這種組提交的思想，加入組提交后的Binlog Parallel Flush優化，如下圖所示。

在Binlog Parallel Flush優化中，每個事務需要串行地分配GTID和Binlog Buffer空間，隨后多個組可以并行地寫Binlog Buffer，在等待Redo log持久化和后臺線程寫Binlog完成后，整組事務就可以提交。

Binlog持久化

在Binlog Parallel Flush優化中，Binlog文件由一個后臺線程周期性的進行持久化，默認持久化周期為每秒一次。

參數介紹

loose_binlog_parallel_flush

Binlog Parallel Flush的功能開關。全局系統變量，取值：on或off。修改本參數立刻生效，不需要重啟實例。

優化效果

測試環境

選取RDS MySQL四種不同規格做測試對比，如表格所示。

參數設置

測試實例使用高性能參數模板，該模板中兩個性能相關參數的配置為：sync_binlog = 1000、innodB_flush_log_at_trx_commit = 2。

測試腳本

使用SysBench的oltp_update_non_index腳本進行性能測試，測試的數據量為100張表，每張表有10萬行數據。

測試結果

測試結果如下圖所示。高并發性能下，Parallel Flush與MySQL原生的Normal Flush相比，有明顯的性能提升，峰值性能提升在10%到30%之間。