slave_preserve_commit_order 这个参数文档上说是维持顺序，保持跟master一致，但是这个很容易理解成不能并发的组顺序乱序应用，其实不是，这个是指能并发执行的事务间的乱序。所以这个参数关闭后，从库在并行复制的时候，也会出现“Waiting for dependent transaction to commit“ 状态，这个在压测环境很容易复现

slave1 [localhost] {msandbox} ((none)) > show processlist;
+----+-------------+-----------+------+---------+-------+---------------------------------------------+------------------+
| Id | User        | Host      | db   | Command | Time  | State                                       | Info             |
+----+-------------+-----------+------+---------+-------+---------------------------------------------+------------------+
|  1 | system user |           | NULL | Connect | 15602 | Waiting for master to send event            | NULL             |
|  2 | system user |           | NULL | Connect |     0 | Waiting for dependent transaction to commit | NULL             |
|  3 | system user |           | NULL | Connect |     6 | System lock                                 | NULL             |
|  4 | system user |           | NULL | Connect |     6 | System lock                                 | NULL             |
|  5 | system user |           | NULL | Connect |     6 | System lock                                 | NULL             |
|  6 | system user |           | NULL | Connect |     6 | Waiting for an event from Coordinator       | NULL             |
| 10 | msandbox    | localhost | NULL | Query   |     0 | starting                                    | show processlist |
+----+-------------+-----------+------+---------+-------+---------------------------------------------+------------------+
7 rows in set (0.00 sec)
slave1 [localhost] {msandbox} ((none)) > show variables like '%order%';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| binlog_order_commits        | ON    |
| slave_preserve_commit_order | OFF   |
+-----------------------------+-------+
2 rows in set (0.01 sec)

下面看下代码

schedule_next_event -> wait_for_last_committed_trx -> stage_worker_waiting_for_commit_parent

在遇到事务开始，先调度下一个event。schedule_next_event,调度这里判断是否能并行，不能并行就等待，然后分配worker，在获取worker这里，get_least_occupied_worker这里根据参数slave_preserve_commit_order判断是否有order_commit_manager,有就加入顺序队列，没有就不加了。所以这里看是先判断是否能并行执行的，能并行调度才找的worker，所以slave_preserve_commit_order是在可并行的前提下，是否顺序应用的。

下面是获取worker的流程

在获取worker的时候，如果之前分配了，就直接使用就行了说明队列里已经注册过了，如果最近没有，那么在空闲worker里找一个，如果空闲worker没有，那么进入stage_slave_waiting_for_workers_to_process_queue状态。如果在空闲中找到一个，如果设置了slave_preserve_commit_order,就注册下，worker放入顺序队列中。

所以说乱序，是worker注册顺序问题，注册的早，event分配到这个worker，执行的就早。

这个参数不保证非事务性的更新的顺序，这样就可能导致出现gap, relay_log_recovery 能解决gap和不一致的的情况。