在支持 并行复制的 Mysql 版本中，从库中负责执行 relay log 的 线程 sql_thread 被分成
一个 coordination 线程 和 多个 work 线程，具体可以设置 work 线程数量，具体实现应该是使用类似线程池的方式。
每个版本有自己不同的 relay log 分配策略。
思路：
1.按表分发事务：如果多个事务更改同一个表，则最后变成单线程执行，作用不大。
每次 coordination 线程在 取 relay log 的时候，都会检查取得 relay log 的事务（按事务为单位取 relay log ？），并且分析这个事务中涉及到修改的表 的集合
1. 如果 集合 中的表 和 当前的 work 们修改的表 没有冲突，则可以直接将这个事务分配给 任意一个 work
2. 如果 集合 中的表 和 当前的 work 们的一个 work 有冲突，则直接分配给这个 work
3. 倘若 集合 中的表 和 多于 一个 work 有冲突，则coordination 线程 等待，直到只有一个 work 修改的表和 这个事务有冲突，进行 2
2.按行分发：需要解析 binlog ，太耗费资源，不被使用
3.(5.7 slave-parallel-type = DATABASE)按库分发：不常用
4.(5.7 slave-parallel-type = LOGIC_CLOCK)按照 commit_id 分发
redolog 可以组提交，意味着组提交的一组事务是可以并行执行的，因为如果不能并行执行（比如被行锁锁住），那么就不能执行 commit 事务，不能进入 prepare write 阶段，必须进入 prepare write 阶段才能使用组提交，所以可以组提交的事务们一定是能够并行执行的。将同一组事务 打上相同的 commit_id ，写入 binlog
以此，有相同 commit_id 的事务会被分发到不同的线程 ，因为他们可以并行执行。所以如果主库能够组提交更多的事务，并且从库能够开多一点线程，那么主从同步效率很高。
5.（5.7.22 控制参数 binlog-transaction-dependency-tracking）
COMMIT_ORDER : 也就是 4
WRITESET : 按照WRITE_SET , 这个 set 里的东西是 （库+表名+所有唯一索引名+所有唯一索引的值） 的 hash 值（这个hash记在binlog 中每条语句后面，以此来唯一识别一行，为什么有了主键索引，还要其他唯一索引呢？主键索引已经可以唯一识别一行了吧？）， 每个事务都有自己的 WRITE_SET ，两个事务只有 SET 里的 hash 值都不相同，才能并行执行（如果无主键和唯一索引，则），表明这两个事务不会修改同一行。和2.按行分发的差不多，但是有点在于不用解析 binlog ，节省CPU时间，并且binlog 不要求是 row 格式。
WRITESET_SESSION : 被同一个session 执行的事务，也就是被同一个线程执行的事务，在从库也保证先后顺序执行