影响主库的并发度的原因就是各种锁，由于 InnoDB 引擎支持行锁，除了所有并发事务都在更新同一行（热点行）这种极端场景外，它对业务并发度的支持还是很友好的
而relay log日志在备库上的执行，就是备库上 sql_thread 更新数据 (DATA) 的逻辑，MySQL 5.6 版本之前，只支持单线程复制；为了解决备库执行效率，从单线程复制到最新版本的多线程复制，中间的演化经历了好几个版本
基本原理：
coordinator （原来的 sql_thread）不再直接更新数据了，只负责读取中转日志和分发事务。真正更新日志的，变成了 多个worker 线程。而 work 线程的个数，就是由参数 slave_parallel_workers 决定的（建议设置在8~16之间）
coordinator 在分发的时候，需要满足以下这两个基本要求：
1）不能造成更新覆盖。这就要求更新同一行的两个事务，必须被分发到同一个 worker 中。
2）同一个事务不能被拆开，必须放到同一个 worker 中。
版本一：按表分发策略
基本思路是，如果两个事务更新不同的表，它们就可以并行。因为数据是存储在表里的，所以按表分发可以保证两个 worker 不会更新同一行。如果有跨表的事务，还是要把两张表放在一起考虑的。
每个 worker 线程对应一个 hash 表，用于保存当前正在这个 worker 的“执行队列”里的事务所涉及的表。hash 表的 key 是“库名. 表名”，value 是一个数字，表示队列中有多少个事务修改这个表。
每个事务在分发的时候，跟所有 worker 的冲突关系包括以下三种情况：
1）如果跟所有 worker 都不冲突，coordinator 线程就会把这个事务分配给最空闲的 woker;
2）如果跟多于一个 worker 冲突，coordinator 线程就进入等待状态，直到和这个事务存在冲突关系的 worker 只剩下 1 个；
3）如果只跟一个 worker 冲突，coordinator 线程就会把这个事务分配给这个存在冲突关系的 worker。
缺点：碰到热点表，所有事务都会被分配到同一个 worker 中，就变成单线程复制了。
版本二：按行复制
核心思路是：如果两个事务没有更新相同的行，它们在备库上可以并行执行。要求 binlog 格式必须是 row。
按行复制和按表复制的数据结构差不多，也是为每个 worker，分配一个 hash 表。要实现按行分发， key就必须是“库名 + 表名 + 唯一键的值”。这个“唯一键”只有主键 id 还是不够的，还需要考虑唯一键。key 应该是“库名 + 表名 + 索引 a 的名字 +a 的值。要求
1）要能够从 binlog 里面解析出表名、主键值和唯一索引的值。主库的 binlog 格式必须是 row；
2）表必须有主键；
3）不能有外键。表上如果有外键，级联更新的行不会记录在 binlog 中，冲突检测就不准确。
按行并行策略在决定线程分发的时候，需要消耗更多的计算资源：
1）耗费内存。比如一个语句要删除 100 万行数据，这时候 hash 表就要记录 100 万个项。
2）耗费 CPU。解析 binlog，然后计算 hash 值，对于大事务，这个成本还是很高的
版本三：按库并行。
决定分发策略的 hash 表里，key 就是数据库名。这个策略的并行效果，取决于压力模型。如果在主库上有多个 DB，并且各个 DB 的压力均衡，使用这个策略的效果会很好。
版本四：MariaDB 并行复制策略
MariaDB 并行复制策略，利用了redo log 组提交 (group commit) 特性：
1）能够在同一组里提交的事务，一定不会修改同一行；
2）主库上可以并行执行的事务，备库上也一定是可以并行执行的。
MariaDB 是这么做的：
1）在一组里提交的事务，有相同的 commit_id，下一组就是 commit_id+1；commit_id 直接写到 binlog 里面；
2）传到备库时，相同 commit_id 的事务分发到多个 worker 执行；
3）这一组全部执行完成后，coordinator 再去取下一批。
之前的思路都是在“分析 binlog，并拆分到 worker”上。而 MariaDB 的这个策略，目标是“模拟主库的并行模式”。
缺点：必须等前一个事务完全执行完成，下一组才能开始执行。遇到大事务，只有一个 worker 线程在工作，是对资源的浪费。
版本五：官方的并行复制策略
官方的 MySQL5.7 版本也提供了类似的功能，由参数 slave-parallel-type 来控制并行复制策略：
1）配置为 DATABASE，表示使用 MySQL 5.6 版本的按库并行策略；
2）配置为 LOGICAL_CLOCK，表示的就是类似 MariaDB 的策略。
MariaDB 策略核心是“所有处于 commit”状态的事务可以并行。事务处于 commit 状态，表示已经通过了锁冲突的检验。其实，不用等到 commit 阶段，只要能够到达 redo log prepare 阶段（参考细化后的2阶段提交图，五步中的第三步），就表示事务已经通过锁冲突的检验了。
MySQL 5.7 针对并行度做了优化，并行复制策略的思想是：
1）同时处于 prepare 状态的事务，在备库执行时是可以并行的；
2）处于 prepare 的事务，与处于 commit 的事务之间，在备库执行时也是可以并行的。
binlog 组提交的两个参数：
1）binlog_group_commit_sync_delay 参数，表示延迟多少微秒后才调用 fsync;
2）binlog_group_commit_sync_no_delay_count 参数，表示累积多少次以后才调用 fsync。
两个参数拉长 binlog 从 write 到 fsync 的时间，减少 binlog 的写盘次数。也可以用来制造更多的“同时处于 prepare 阶段的事务”。这样就增加了备库复制的并行度。
版本六：基于 WRITESET 的并行复制。
参数 binlog-transaction-dependency-tracking，用来控制是否启用这个新策略。
1）COMMIT_ORDER，就是前面介绍的，根据同时进入 prepare 和 commit 来判断是否可以并行的策略。
2）WRITESET，事务涉及更新行，计算出 hash 值，组成集合 writeset。如果两个事务没有操作相同的行，就可以并行。（这个 hash 值是通过“库名 + 表名 + 索引名 + 值”计算出来的）
3）WRITESET_SESSION，是在 WRITESET 的基础上多了一个约束，即在主库上同一个线程先后执行的两个事务，在备库执行的时候，要保证相同的先后顺序。
