1、binlog_transaction_dependency_tracking =commit_order

last_committed表示事務提交的時候，上次事務提交的編號，如果事務具有相同的last_committed，表示這些事務都在一組內，可以進行並行的回放。

在commit_order模式下，如果事務具有相同的last_committed，一定是在不同執行緒執行的；反之，同一個執行緒執行的事務，last_committed必然不同。

一個組提交的事務都是可以並行回放，因為這些事務都已進入到事務的prepare階段，則說明事務之間沒有任何衝突（否則就不可能提交）。

2、 binlog_transaction_dependency_tracking =writeset

可以看到在 write_set模式下，各個insert是可以並行執行的，所以它們被分到了同個組(last_committed相同)。

簡單來說，WriteSet並行複製的思想是： 不同事務的不同記錄不重疊，則都可在從機上並行回放，可以看到並行的力度從組提交細化為記錄級。

所謂不同的記錄，在MySQL中用WriteSet物件來記錄每行記錄，從原始碼來看WriteSet就是每條記錄hash後的值（必須開啟ROW格式的二進位制日誌），具體演算法如下：

WriteSet=hash(index_name | db_name | db_name_length | table_name | table_name_length | value | value_length

產生的WriteSet物件會插入到WriteSet雜湊表，雜湊表的大小由引數binlog_transaction_dependency_history_size設定，預設25000。WriteSet雜湊表的型別為std::map<uint64,int64>，儲存每條記錄的WriteSet值和對應的sequence_number。

當事務每次提交時，會計算修改的每個行記錄的WriteSet值，然後查詢雜湊表中是否已經存在有同樣的WriteSet，若無，WriteSet插入到雜湊表，寫入二進位制日誌的last_committed值不變。若有，則last_committed值更新為sequnce_number。

last_committed和sequence_number代表的就是所謂的LOGICAL_CLOCK

WriteSet的效能比Commit_Order要快5~6倍，效果非常明顯。如果是有延遲要追的，WriteSet毫無疑問是勝者。Commit_Order的瓶頸依然是需要主有足夠的併發度，實際生產上確很難達到，除非是業務高峰期。

3、binlog_transaction_dependency_tracking =writeset_session

WRITESET_SESSION，是在 WRITESET 的基礎上多了一個約束，即在主庫上同一個執行緒先後執行的兩個事務，在備庫執行的時候，要保證相同的先後順序。

參考文件：

https://www.cnblogs.com/VicLiu/p/14653400.html

https://blog.csdn.net/weixin_33945512/article/details/113594838

mysql 並行複製原理

相關文章