Mysql各版本 - 从库多线程执行 relay log

在支持 并行复制的 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 执行的事务，也就是被同一个线程执行的事务，在从库也保证先后顺序执行