mysql 8.0的writeset并行复制通过主库生成事务写集（writeset）、从库依据行级冲突判断并行回放，彻底解决单库单表场景下的单线程瓶颈；需主库设binlog_transaction_dependency_tracking=writeset、row格式及gtid，从库设slave_parallel_type=logical_clock且配合slave_parallel_workers与slave_preserve_commit_order。
MySQL 8.0 的 WRITESET 并行复制机制直接解决单线程瓶颈
旧版本（如 5.6/5.7）的并行复制依赖 slave_parallel_type=DATABASE 或 LOGICAL_CLOCK，前者要求事务写入不同库才能并行，后者仍受限于事务提交顺序和依赖图计算开销。MySQL 8.0 默认启用 WRITESET 策略，核心是：每个事务在主库生成时，会根据修改的行计算出一个写集（writeset），即所有被更新的主键/唯一键哈希值；从库据此判断事务间是否真正冲突——无交集即可安全并行回放。
这意味着：即使所有 DML 都发生在同一张表、同一个库，只要修改的行不重叠（比如 UPDATE users SET name='a' WHERE id=1 和 UPDATE users SET name='b' WHERE id=2），就能同时执行。实测中，TPS 提升常达 5–10 倍，远超旧版逻辑时钟方案。
-
binlog_transaction_dependency_tracking=WRITESET必须在主库开启，否则从库无法获取 writeset 信息 - 从库需设
slave_parallel_type=LOGICAL_CLOCK（8.0 中WRITESET是 tracking 方式，不是 parallel_type） - 主库
binlog_format必须为ROW，MIXED或STATEMENT下 writeset 不生效
GTID + 自动位置点跳过与恢复大幅减少人工干预延迟
MySQL 8.0 强制推荐 GTID 模式（gtid_mode=ON），配合 enforce_gtid_consistency=ON，让每个事务拥有全局唯一标识。当从库 SQL 线程因错误中断（如唯一键冲突、表不存在），不再需要手动解析 relay log 找 position、用 CHANGE MASTER TO ... RELAY_LOG_FILE/POS 跳过——而是直接执行 SET GTID_NEXT='xxx-xxx-xxx:12345'; BEGIN; COMMIT; 即可跳过单个事务，且后续自动对齐。整个过程秒级完成，避免旧版本中因人工定位错误位置导致数分钟甚至数小时的累积延迟。
- 跳过前必须确认该事务在业务上可丢弃（如幂等性操作失败）
- 误设
GTID_NEXT可能导致数据不一致，建议搭配SELECT GTID_SUBSET()校验 - 从库重启后，GTID 自动识别已执行事务，无需再靠
MASTER_AUTO_POSITION=1以外的方式同步起点
从库参数默认更激进，但需注意隐性风险
MySQL 8.0 对从库关键参数做了更合理的默认值调整，例如 slave_parallel_workers 默认为 4（5.7 为 0），slave_preserve_commit_order 默认为 ON（保障事务提交顺序不被并行打乱）。这些降低了配置门槛，但也带来新问题：
- 若从库 CPU 核数不足 4，
slave_parallel_workers=4反而引发线程争抢，应设为min(4, CPU核数) -
slave_preserve_commit_order=ON在高并发小事务场景下，可能因等待 commit order 同步而轻微拖慢吞吐，压测时可临时关掉对比 - 旧版习惯性调大
innodb_buffer_pool_size到 80%，但在 8.0 中若启用了innodb_dedicated_server=ON，该值会被自动推导，手动设置反而覆盖自适应逻辑
延迟监控更准，但 Seconds_Behind_Master 仍有盲区
MySQL 8.0 改进了 Seconds_Behind_Master 的计算逻辑：它现在基于 binlog event 中更精确的时间戳（而非仅依赖系统时间差），并在大事务执行期间尝试估算剩余时间。但本质没变——它仍是“当前正在执行的事务”与主库时间的差值。所以当从库卡在某个长事务（如大 ALTER TABLE）或锁等待（MDL、行锁）时，这个值可能长时间显示为 0 或很小，实际已落后百万行。
真正可靠的监控必须结合外部工具：pt-heartbeat 写入时间戳表并从从库读取差值，或用 Prometheus + mysqld_exporter 抓取 mysql_slave_status_seconds_behind_master 指标并叠加 mysql_slave_sql_running 状态判断。
WRITESET 并行能力再强，也救不了被 MDL 锁住的 SQL 线程——这点容易被忽略，排查时永远先看 SHOW PROCESSLIST 里 SQL 线程的状态，而不是只盯 Seconds_Behind_Master。
