MySQL 5.7.22 的并行复制策略

在 2018 年 4 月份公布的 MySQL 5.7.22 版本里，MySQL 减少了一个新的并行复制策略，基于 WRITESET 的并行复制。

相应地，新增了一个参数 binlog-transaction-dependency-tracking，用来管制是否启用这个新策略。这个参数的可选值有以下三种。

1. COMMIT_ORDER，示意的就是后面介绍的，依据同时进入 prepare 和 commit 来判断是否能够并行的策略。
2. WRITESET，示意的是对于事务波及更新的每一行，计算出这一行的 hash 值，组成汇合 writeset。如果两个事务没有操作雷同的行，也就是说它们的 writeset 没有交加，就能够并行。
3. WRITESET_SESSION，是在 WRITESET 的根底上多了一个束缚，即在主库上同一个线程先后执行的两个事务，在备库执行的时候，要保障雷同的先后顺序。

当然为了惟一标识，这个 hash 值是通过“库名 + 表名 + 索引名 + 值”计算出来的。如果一个表上除了有主键索引外，还有其余惟一索引，那么对于每个惟一索引，insert 语句对应的 writeset 就要多减少一个 hash 值。

你可能看进去了，这跟咱们后面介绍的基于 MySQL 5.5 版本的按行散发的策略是差不多的。不过，MySQL 官网的这个实现还是有很大的劣势：

1. writeset 是在主库生成后间接写入到 binlog 外面的，这样在备库执行的时候，不须要解析 binlog 内容（event 里的行数据），节俭了很多计算量；
2. 不须要把整个事务的 binlog 都扫一遍能力决定散发到哪个 worker，更省内存；
3. 因为备库的散发策略不依赖于 binlog 内容，所以 binlog 是 statement 格局也是能够的。

因而，MySQL 5.7.22 的并行复制策略在通用性上还是有保障的。

当然，对于“表上没主键”和“外键束缚”的场景，WRITESET 策略也是没法并行的，也会临时进化为单线程模型。