MySQL从库SQL线程并发冲突的本质是事务间写集重叠或逻辑时序约束导致的串行化回退，而非并发本身引发；表现为worker线程因锁等待或依赖关系被coordinator中断重试，最终退化为单线程回放。
MySQL从库SQL线程并发冲突的本质是什么
MySQL 5.6 引入基于库（database）的并行复制，5.7 支持基于组提交（group commit）的逻辑时钟（MTS），8.0 默认启用 WRITESET 并行复制。所谓“SQL线程并发冲突”，其实是多个 worker 线程尝试同时更新同一行、同一表、甚至同一 schema 时，因锁等待或事务依赖关系被 coordinator 中断重试，最终退化为单线程回放。
关键点在于：冲突不是由并发本身引发的，而是由事务间写集（writeset）重叠或逻辑时序约束导致的串行化回退。
- 冲突常见现象：
Seconds_Behind_Master波动剧烈、Slave_SQL_Running_State频繁显示Waiting for dependent transaction to commit或Reading event from the relay log - 根本原因不是 CPU 或 IO 不足，而是 coordinator 对 worker 的调度阻塞
- 即使开启了
slave_parallel_workers > 0，若主库写入高度集中于单表或单库，实际并行度仍接近 0
如何验证当前并行复制是否真正生效
不能只看 slave_parallel_workers 是否大于 0，得查实时运行态：
- 查看活跃 worker 数：
SELECT * FROM performance_schema.replication_applier_status_by_worker;
- 关键字段：
LAST_APPLIED_TRANSACTION应有多个不同值；PROCESS_ID非空表示正在运行；LAST_ERROR_NUMBER若非 0 要警惕 - 查看 coordinator 分发情况：
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;
中WORKERS_PROCESSED_GROUPS和WORKERS_WAITING_GROUPS比值持续偏低（如 - 检查复制参数是否被 runtime 覆盖：
SHOW VARIABLES LIKE 'slaveparallel%';，特别注意slave_parallel_type是DATABASE、LOGICAL_CLOCK还是WRITESET
WRITESET 模式下必须调优的三个参数
MySQL 8.0 默认用 slave_parallel_type = WRITESET，但若主库未开启对应支持，它会自动降级为 LOGICAL_CLOCK，导致并行效果打折：
- 主库必须设：
binlog_transaction_dependency_tracking = WRITESET（默认值，但建议显式确认） - 主库必须设：
binlog_format = ROW（STATEMENT 或 MIXED 下 WRITESET 不生效） - 从库需调：
slave_preserve_commit_order = ON（仅在slave_parallel_type = LOGICAL_CLOCK时强制要求；WRITESET 下可关，但开启后能更好保障一致性，尤其在主库有跨表 FK 或触发器时）
其他影响显著的配置：
-
slave_parallel_workers：建议设为 CPU 核数 × 1.5～2，但超过 16 后收益递减，且可能加剧 relay log 锁竞争 -
slave_checkpoint_period：默认 300ms，高压力下可缩短至 50～100ms，加快故障恢复定位，但会略微增加刷盘开销
为什么开了并行复制，单表写入性能反而更差
这是典型误配场景：当所有 DML 都集中在一张大表（如 user_log）上，WRITESET 会为每条语句计算涉及的主键/唯一键哈希，结果大量事务写集哈希值相同 → 被路由到同一个 worker → 实际仍是单线程回放，还额外增加了 coordinator 分发和 writeset 计算开销。
此时应考虑：
- 主库端拆分写入：按时间分表 + 应用层路由，或引入消息队列削峰
- 从库端临时切回
slave_parallel_type = DATABASE（前提是业务写库分散） - 关闭并行复制：
STOP SLAVE SQL_THREAD; SET GLOBAL slave_parallel_workers = 0; START SLAVE SQL_THREAD;，比强行开启更稳 - 检查是否存在长事务阻塞：一个运行 30 秒的 UPDATE 会让所有后续依赖它的事务排队，
SHOW PROCESSLIST中找State: Waiting for preceding transaction to commit
WRITESET 的优势只在多表、多主键、低写集重叠度的 OLTP 场景下才明显；对单表批量导入、日志表追加等场景，它解决不了本质瓶颈。
