mysql 并行复制原理

来源：这里教程网时间：2026-03-01 16:16:20 作者：

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的瓶颈依然是需要主有足够的并发度，实际生产上确很难达到，除非是业务高峰期。回放时和基于COMMIT_ORDER的并行复制一样，具有相同的last_committed值可以并行回放，同一条记录回放，last_committed值必然不同，必须等待之前的一条记录回放完成后才能执行。所以透过现象看本质基于Write Set的方式只是在以前的方式上对last_committed做了更进一步的处理，来达到最大的并发效果。 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