Slave_SQL_Running为No或卡在Reading event from the relay log，表明SQL线程阻塞于执行层，常见原因包括DDL、锁等待、大事务回放失败或relay log损坏；需查Last_SQL_Error定位具体错误，谨慎跳过而非直接START SLAVE。
Slave_SQL_Running为No或状态卡在Reading event from the relay log
这说明从库SQL线程已停止或无法推进，不是网络或IO问题，而是执行层阻塞。常见诱因是DDL操作、锁等待、主库大事务回放失败，或relay log损坏。
实操建议：
- 先检查
SHOW SLAVE STATUS\G中的Last_SQL_Error，若出现Deadlock found when trying to get lock或Lock wait timeout exceeded，说明SQL线程被本地锁阻塞 - 若错误含
Table definition has changed或Unknown table，大概率是relay log中某条语句依赖的表结构与当前从库不一致（比如主库执行了ALTER TABLE后又快速删表） - 不要直接
START SLAVE重试——先用SELECT * FROM mysql.slave_relay_log_info;确认当前执行到哪个relay log文件和位置，再结合mysqlbinlog解析对应日志段定位具体语句 - 临时跳过单条错误（仅限明确可丢弃的非关键语句）：执行
SET GLOBAL sql_slave_skip_counter = 1;后START SLAVE；但MySQL 8.0.23+已废弃该变量，改用STOP REPLICA; SET GTID_NEXT='xxx'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START REPLICA;
Slave_SQL_Running_State显示Waiting for dependent transaction to commit
这是并行复制（slave_parallel_type = LOGICAL_CLOCK）下的典型卡点，表示当前事务在等上游事务提交，不是性能瓶颈，而是事务间存在写集依赖（比如两个事务更新同一行）。此时Seconds_Behind_Master可能仍为0，但实际延迟已在累积。
实操建议：
- 确认是否开启了并行复制：
SELECT @@slave_parallel_type, @@slave_parallel_workers;；若slave_parallel_workers > 0但只有1个Worker线程活跃，说明依赖关系太密，退化成串行 - 查主库最近是否有跨分片/跨表的强一致性事务（如
UPDATE t1 JOIN t2），这类事务天然无法并行；业务上应拆分为独立语句，或用应用层控制顺序 - 避免在主库执行长事务+大量DML混合操作；
autocommit=1且单语句控制在千行以内，能显著降低写集冲突概率 - 监控
SHOW PROCESSLIST中Worker线程的State，若长期停留在Waiting for preceding transaction to commit，说明逻辑时钟调度器频繁等待，需压测验证事务模型
Seconds_Behind_Master持续增长但SQL线程状态正常
这种情况最危险：指标“看起来还行”，实际延迟已达分钟级。根本原因是Seconds_Behind_Master只反映最后一条已执行事件的时间差，在并行复制或GTID模式下，它不统计未调度Worker的任务队列。
实操建议：
- 立刻比对位置差：
SELECT Master_Host, Exec_Master_Log_Pos, Read_Master_Log_Pos FROM performance_schema.replication_applier_status_by_coordinator;；若Read_Master_Log_Pos - Exec_Master_Log_Pos > 10MB，说明中继日志堆积严重 - 用
pt-heartbeat验证真实延迟：pt-heartbeat --host=slave --database=test --monitor --print-master-server-id；它基于时间戳表更新，毫秒级可信 - 检查从库磁盘IO：
iostat -x 1看%util是否持续>90%，await是否>20ms；高IO延迟会拖慢relay log读取和InnoDB写入 - 确认
slave_preserve_commit_order = ON已启用；关闭它会导致并行回放乱序，后续事务可能因缺失前置数据而反复重试，隐形拉长延迟
开启并行复制后延迟反而升高
并行复制不是开个参数就万事大吉。Worker线程数设太高会引发CPU争抢和锁竞争，尤其当从库配置低于主库时，更容易雪上加霜。
实操建议：
-
slave_parallel_workers值别超过从库物理CPU核数；例如8核机器设为6，留2核给OS和监控进程 - 禁用
innodb_thread_concurrency（设为0），否则InnoDB内部线程池会限制并发度，与MySQL层并行机制冲突 - 观察
SHOW ENGINE INNODB STATUS\G里的SEMAPHORES段，若os_waits数值飙升，说明Worker线程在争抢dict_table_t::mutex或trx_sys_t::mutex，需检查是否有高频DROP/CREATE TABLE操作 - MySQL 8.0.30+支持
replica_parallel_workers动态调整，可先设为2运行1小时，再逐步加到4/6，每次调整后用pt-heartbeat对比延迟变化
真实延迟永远藏在位置差和心跳时间戳里，而不是Seconds_Behind_Master那个数字背后。
