Mysql兩階段提交細化流程圖：
其實，不用等到 commit 階段，只要能夠到達 redo log prepare 階段，就表示事務已經通過鎖衝突的檢驗了。
因此，MySQL 5.7 並行複製策略的思想是：
同時處於 prepare 狀態的事務，在備庫執行時是可以並行的；
處於 prepare 狀態的事務，與處於 commit 狀態的事務之間，在備庫執行時也是可以並行的。
兩個參數：
binlog_group_commit_sync_delay 參數，表示延遲多少微秒後才調用 fsync;
binlog_group_commit_sync_no_delay_count 參數，表示累積多少次以後才調用 fsync。
這兩個參數是用於故意拉長 binlog 從 write 到 fsync 的時間，以此減少 binlog 的寫盤次數。在 MySQL 5.7 的並行複製策略裏，它們可以用來製造更多的“同時處於 prepare 階段的事務”。這樣就增加了備庫複製的並行度。
也就是說，這兩個參數，既可以“故意”讓主庫提交得慢些，又可以讓備庫執行得快些。在 MySQL 5.7 處理備庫延遲的時候，可以考慮調整這兩個參數值，來達到提升備庫複製併發度的目的。
MySQL 5.7.22 的並行複製策略
在 2018 年 4 月份發佈的 MySQL 5.7.22 版本里，MySQL 增加了一個新的並行複製策略，基於 WRITESET 的並行複製。
相應地，新增了一個參數 binlog-transaction-dependency-tracking，用來控制是否啓用這個新策略。這個參數的可選值有以下三種。
COMMIT_ORDER，表示的就是前面介紹的，根據同時進入 prepare 和 commit 來判斷是否可以並行的策略。
WRITESET，表示的是對於事務涉及更新的每一行，計算出這一行的 hash 值，組成集合 writeset。如果兩個事務沒有操作相同的行，也就是說它們的 writeset 沒有交集，就可以並行。
WRITESET_SESSION，是在 WRITESET 的基礎上多了一個約束，即在主庫上同一個線程先後執行的兩個事務，在備庫執行的時候，要保證相同的先後順序。
當然爲了唯一標識，這個 hash 值是通過“庫名 + 表名 + 索引名 + 值”計算出來的。如果一個表上除了有主鍵索引外，還有其他唯一索引，那麼對於每個唯一索引，insert 語句對應的 writeset 就要多增加一個 hash 值。
writeset 是在主庫生成後直接寫入到 binlog 裏面的，這樣在備庫執行的時候，不需要解析 binlog 內容（event 裏的行數據），節省了很多計算量；
不需要把整個事務的 binlog 都掃一遍才能決定分發到哪個 worker，更省內存；
由於備庫的分發策略不依賴於 binlog 內容，所以 binlog 是 statement 格式也是可以的。
因此，MySQL 5.7.22 的並行複製策略在通用性上還是有保證的。
當然，對於“表上沒主鍵”和“外鍵約束”的場景，WRITESET 策略也是沒法並行的，也會暫時退化爲單線程模型。