MySQL 8.0 主从延迟高是因并行复制关键配置缺失：binlog_format非ROW、gtid_mode或enforce_gtid_consistency未启用、log_slave_updates=OFF、slave_parallel_type未设为WRITESET。

MySQL 8.0 主从搭建时，从库延迟高不是“迟早会出的问题”，而是配置漏项或默认值不合理导致的即时结果——slave_parallel_workers 设成 8 却仍是单线程回放，Seconds_Behind_Master 从启动就飙升，大概率是四个关键开关没打开。

为什么刚配好主从就延迟飙升？

MySQL 8.0 默认不启用真正有效的并行复制。即使你执行了 SET GLOBAL slave_parallel_workers = 8，只要以下任一条件不满足，SQL 线程仍会静默退回到单线程模式：

• binlog_format 不是 ROW（MIXED 或 STATEMENT 下 WRITESET 直接失效）
• gtid_mode = OFF 或 enforce_gtid_consistency = OFF（WRITESET 依赖 GTID 全局事务标识）
• log_slave_updates = OFF（这不是“级联复制才需要”，而是 slave_preserve_commit_order 生效的前提）
• slave_parallel_type 没显式设为 'WRITESET'（默认是 'DATABASE'，在单库场景下等同于单线程）

执行 SHOW PROCESSLIST 只看到一个 SQL Thread，就是典型信号。

主从初始化阶段必须检查的五项配置

这些不是“建议项”，而是 START SLAVE 前必须确认的硬性前提，缺一不可：

Mysql Skill 1.0.0 (3)

MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。

下载

• 主库确认：SHOW VARIABLES LIKE 'binlog_format' → 必须返回 ROW；SHOW VARIABLES LIKE 'gtid_mode' → 必须为 ON
• 从库确认：SELECT @@log_slave_updates → 必须为 1；SELECT @@slave_parallel_type → 必须为 WRITESET（MySQL 8.0.22+ 推荐）
• 从库确认：SELECT @@slave_parallel_workers → 建议设为 CPU 核心数的 1.5 倍（如 8 核设 12），但前提是前四项已达标
• 主库 my.cnf 中需有：binlog_transaction_dependency_tracking = WRITESET（让主库生成 writeset 信息）
• 从库重启后首次执行 START SLAVE 前，务必先 STOP SLAVE，再 RESET SLAVE 清除旧 relay log 状态

从库磁盘 I/O 高导致延迟时，优先调这三项

延迟持续上涨但网络和 CPU 正常？大概率是 SQL 线程被磁盘卡住。别急着加机器，先看这三个参数是否踩坑：

• innodb_buffer_pool_size：必须设为物理内存的 50%–70%，低于 50% 时 Innodb_buffer_pool_read_requests 与 Innodb_buffer_pool_reads 算出的命中率若 ，说明大量读穿透到磁盘
• log_bin：从库若不作级联复制，必须关闭（SET GLOBAL log_bin = OFF 并在 my.cnf 中注释掉 log-bin 行），否则每条回放语句都双写 binlog + relay log
• tmp_table_size 和 sort_buffer_size：避免设过大（如超过 64M），否则单个大 UPDATE 回放时易触发临时表落盘；更稳妥的是在主库就用覆盖索引规避 Using filesort

延迟监控不能只盯 Seconds_Behind_Master

这个字段在大事务执行中会“冻结”不更新，造成误判。真实反映同步状态的组合是：

• SQL_Remaining_Delay：延迟复制时唯一可信的倒计时字段（非延迟复制时为 NULL）
• Exec_Master_Log_Pos 与 Read_Master_Log_Pos 的差值：持续扩大说明 IO 线程收日志正常，但 SQL 线程处理不过来
• Retrieved_Gtid_Set 和 Executed_Gtid_Set 的差异：GTID 模式下比位点更准，尤其跨故障恢复后

最易被忽略的是：SHOW SLAVE STATUS\G 输出里 Slave_SQL_Running_State 显示 Waiting for dependent transaction to commit —— 这说明 WRITESET 正在起作用，不是卡死，是主动等待冲突事务释放。