MySQL 5.7从库默认单线程回放，因slave_parallel_workers默认为0且未启用LOGICAL_CLOCK模式；必须同时配置主库binlog_transaction_dependency_tracking=WRITESET、从库slave_parallel_type=LOGICAL_CLOCK和slave_parallel_workers≥2才启用行级并行。
为什么MySQL 5.7的从库默认还是单线程回放？
MySQL 5.6 开始支持按库（database）并行复制，但实际效果受限于业务分库不均——比如所有写操作集中在 sysbench_db 这一个库，那 slave_parallel_workers 再设成 8 也只会用上 1 个线程。5.7 引入了基于 WRITESET 的并行复制机制，它不再依赖库名，而是根据事务修改的**行级唯一键哈希值**判断是否冲突，真正让并发回放落地可行。但这个能力默认是关闭的，必须手动开启对应参数组合。
启用WRITESET并行复制必须配齐的3个参数
只改 slave_parallel_workers 是无效的，5.7 的 WRITESET 并行需要三者协同：
-
slave_parallel_type = LOGICAL_CLOCK：启用逻辑时钟调度器（不是DATABASE） -
slave_parallel_workers = N（N ≥ 2）：建议从 4 起步，最大不超过 CPU 核心数 × 1.5 -
binlog_transaction_dependency_tracking = WRITESET：主库也得开——否则 binlog 里不带 WRITESET 元数据，从库根本无法做冲突判定
注意：binlog_transaction_dependency_tracking 是主库参数，必须在主库 my.cnf 中配置并重启生效；从库只管消费和调度。
常见卡顿点：主库没开 WRITESET，从库白配参数
现象：show slave status\G 显示 Seconds_Behind_Master 持续上涨，Slave_SQL_Running_State 长时间停在 “Waiting for preceding transaction to commit”。
原因：主库仍用默认的 COMMIT_ORDER 模式生成 binlog，从库拿到的 relay log 缺少 WRITESET hash 值，逻辑时钟调度器退化为单线程串行回放。
验证方法：
- 主库执行：
SELECT @@binlog_transaction_dependency_tracking;—— 必须返回WRITESET - 查 binlog：
mysqlbinlog -v --base64-output=DECODE-ROWS mysql-bin.000001 | grep -A5 "writeset"—— 应能看到### WRITESET: ...行
性能差异：WRITESET vs DATABASE 并行的实际效果
在 Sysbench oltp_write_only 场景（单库、多表、高并发更新）下实测对比（4核8G 从库）：
-
slave_parallel_type = DATABASE+ 4 workers：延迟稳定在 15–30 秒（所有事务挤在sysbench_db库） -
slave_parallel_type = LOGICAL_CLOCK+WRITESET+ 4 workers：延迟压到 0.3–1.2 秒
关键限制：WRITESET 依赖主键或唯一键。如果表没主键、没唯一索引，MySQL 会自动降级为 COMMIT_ORDER 模式记录依赖关系，这部分事务仍只能串行。所以务必检查从库同步的表是否都具备有效唯一约束。
