slave_preserve_commit_order=on仅在启用logical_clock并行复制时生效，强制worker按主库last_committed顺序提交以避免唯一键冲突，但会降低吞吐、不可动态修改，需重启实例。
不能靠它“保证顺序”来修复数据不一致，它只在特定并行复制场景下约束提交时序，开错反而拖慢同步速度。
slave_preserve_commit_order=ON 什么时候真正起作用
这个参数只在启用并行复制（slave_parallel_workers > 0）且使用 LOGICAL_CLOCK 模式时才有意义。它不控制 relay log 里事务的读取或执行顺序，而是强制 worker 线程在最终 COMMIT 阶段按主库的 last_committed 顺序排队提交。
常见误判是以为开了它就能让从库“完全复刻主库行为”，其实它只解决一个点：避免两个本该有因果关系的事务（比如先删后插同一主键）在从库上因并行回放导致提交乱序、引发唯一键冲突或主键重复错误。
- 必须搭配
slave_parallel_type = LOGICAL_CLOCK（MySQL 5.7+ 默认值） - 必须确保主库开启了组提交（
binlog_group_commit_sync_delay = 0且binlog_group_commit_sync_no_delay_count不过大） - 如果主库用了
MIXED或STATEMENTbinlog 格式，含UUID()、NOW()的语句会降级为单线程提交 →last_committed断层 → 该参数失去调度依据
为什么默认是 OFF，开了反而可能变慢
slave_preserve_commit_order = OFF 是 MySQL 5.7+ 默认值，不是疏忽，而是权衡结果。一旦设为 ON，coordinator 线程必须给每个事务分配一个“提交锁”，worker 线程完成执行后得等前面事务 commit 完才能提交自己——这本质上又引入了串行化瓶颈。
典型卡顿现象：SHOW PROCESSLIST 里看到大量 Waiting for commit lock 状态；Seconds_Behind_Master 波动剧烈但不持续下降。
- 仅当从库报错类似
Duplicate entry 'xxx' for key 'PRIMARY'且确认是因并行回放导致提交乱序时，才考虑开启 - 开启前务必确认
slave_parallel_workers≥ 4，否则 coordinator + worker 架构本身没生效，开这个参数纯属加锁不干活 - 性能代价明显：实测在高并发写入场景下，开启后吞吐可能下降 15%~30%，尤其当主库
last_committed连续性差时
修改它需要停掉整个复制链路
这个参数不能在线动态修改。你执行 SET GLOBAL slave_preserve_commit_order = ON 会直接报错：ERROR 1238 (HY000): Variable 'slave_preserve_commit_order' is a read only variable。
正确流程只有一步：停复制 → 改配置文件 → 重启 MySQL 实例 → 启动复制。
- 停复制命令：
STOP SLAVE; - 配置文件中添加：
slave_preserve_commit_order = ON（必须写在[mysqld]段下） - 重启后检查是否生效：
SELECT @@slave_preserve_commit_order;返回 1 即成功 - 注意：改完不重启，或只执行
START SLAVE而没重启 mysqld，参数不会加载
比调这个参数更关键的三件事
真正影响主从一致性与同步延迟的，往往不是 slave_preserve_commit_order，而是它依赖的前提条件是否扎实。
-
slave_parallel_workers必须 > 0，建议设为 CPU 核心数的 2–4 倍（如 8 或 16），否则并行复制压根没启动 -
master_info_repository和relay_log_info_repository必须设为TABLE，否则 crash safe 失效，恢复时可能跳过或重放事务 - 主库
sync_binlog = 1且innodb_flush_log_at_trx_commit = 1，否则主库崩溃后 binlog 与 redo log 可能不一致，从库再怎么保序也追不出正确状态
参数本身只是最后一道保险丝，底座不牢，接再多保险丝也没用。
