MySQL 5.6+默认SQL线程仍为单线程，即使启用slave_parallel_workers，若未满足ROW格式+GTID+LOGICAL_CLOCK等前提，并行复制实际退化为串行；大事务、从库负载高或IO瓶颈均会加剧延迟。
MySQL 5.6+ 默认 SQL 线程仍是单线程
很多人误以为开启多线程 IO（slave_parallel_workers > 0）就等于复制变快了，其实不然：SQL 回放线程默认仍是单线程，哪怕 slave_parallel_type 设为 LOGICAL_CLOCK，若未正确启用 GTID 或 binlog 格式不满足要求，实际仍退化为串行执行。
关键判断依据是：SHOW SLAVE STATUS\G 中的 Slave_SQL_Running_State 如果长期卡在 Reading event from the relay log，且 Seconds_Behind_Master 持续上涨，基本可锁定是 SQL 线程瓶颈。
- MySQL 5.6 单线程回放是硬限制，不支持并行；5.7 开始支持
slave_parallel_type = DATABASE；8.0+ 才默认启用LOGICAL_CLOCK并依赖 write-set -
slave_parallel_workers值设得再大，若slave_parallel_type是OFF或DATABASE但事务跨库频繁，worker 实际闲置率极高 - 查看是否真正并行：查
performance_schema.replication_applier_status_by_coordinator，看WORKERS列是否 > 1，且APPLYING_EVENT状态分散在多个 worker 上
ROW 格式 + GTID 是并行复制的前提条件
并行复制不是开个参数就生效的魔法开关。MySQL 要安全地把事务分发给多个 worker 并行执行，必须能准确判断事务间无冲突——这只有在 binlog_format = ROW 且启用 GTID 的前提下才能做到。
STATEMENT 模式下，一个 UPDATE t SET c=NOW() 在主从上执行时间不同，结果就可能不一致；而 ROW 记录的是具体哪几行被改了，write-set 才能据此推导出“哪些事务可并发”。
- 检查主库：
SELECT @@binlog_format, @@gtid_mode, @@enforce_gtid_consistency，三者必须为'ROW'、'ON'、'ON' - 从库也要确认
gtid_mode=ON，否则即使主库开了，从库仍按传统 position 复制，无法启用并行逻辑 -
binlog_row_image = MINIMAL建议同步开启，减少 relay log 体积，间接缓解 SQL 线程读取压力
大事务会强制阻塞整个并行队列
哪怕你配了 8 个 worker，只要 relay log 里出现一个耗时 30 秒的大事务（比如单条 UPDATE 影响 200 万行），它就会独占一个 worker，其他 worker 只能等它提交后才开始处理后续事务——并行效果瞬间归零。
这类事务在 SHOW PROCESSLIST 里常表现为 Updating 或 Writing to net，但在 SHOW SLAVE STATUS 中只体现为 Seconds_Behind_Master 缓慢爬升，容易被忽略。
- 主库侧应禁止超大事务：用
max_allowed_packet限大小，配合应用层拆分（如每次UPDATE ... LIMIT 5000） - 从库侧可通过
pt-heartbeat监控端到端延迟，比Seconds_Behind_Master更早暴露大事务拖尾问题 - 发现大事务后，不要直接跳过（
SET GLOBAL sql_slave_skip_counter = 1风险极高），优先查清是否缺失索引导致全表扫描
从库负载高会让 SQL 线程雪上加霜
SQL 线程本质是个普通 MySQL 连接，它执行 INSERT/UPDATE/DELETE 时同样要走查询优化器、加锁、刷盘。如果从库同时跑着大量业务查询，CPU、IO、锁资源全被争抢，SQL 线程自然更慢。
典型现象是 iostat -x 1 显示 %util 接近 100%，pidstat -p $(pidof mysqld) 1 显示 mysqld 进程 %iowait 高，但 SHOW PROCESSLIST 里 SQL 线程状态却是 update 或 query end。
- 从库务必设
read_only = ON（注意：super 权限用户仍可写，需额外管控） - 避免在从库执行
SELECT ... FOR UPDATE或长时间运行的分析类查询 - 磁盘选 NVMe，
innodb_io_capacity和innodb_io_capacity_max按实际 IOPS 设置，别沿用默认值
真实延迟往往不是单一原因。最常被忽略的是：你以为在优化 SQL 线程，其实 IO 线程早就卡在磁盘刷 relay log 上了——Relay_Log_Space 持续增长却不见 Exec_Master_Log_Pos 推进，就得立刻去看从库的磁盘写入能力。
