执行show slave status\G，重点观察Slave_IO_Running、Slave_SQL_Running和Seconds_Behind_Master：若前者为Yes后者为No，说明SQL线程卡住；若两者均为Yes但延迟持续上涨，则SQL回放慢，常见于大事务、磁盘I/O瓶颈或并行复制配置不当。
怎么看 IO 线程和 SQL 线程是否卡住
直接执行 show slave status\G，重点盯三个字段：Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master。如果前者是 Yes 而后者是 No，说明 IO 没问题，SQL 线程挂了或卡在某条语句上；如果两者都是 Yes 但 Seconds_Behind_Master 持续上涨，大概率是 SQL 回放慢。
进一步确认卡点位置：
-
Slave_IO_State显示Waiting for master to send event→ IO 正常，主库没新日志可推 -
Slave_SQL_Running_State是Reading event from the relay log或Waiting for dependent transaction to commit→ SQL 线程在读 relay log 或等上游事务提交，典型大事务/DDL 阻塞信号 -
Relay_Master_Log_File和Master_Log_File不一致，且Read_Master_Log_Pos远大于Exec_Master_Log_Pos→ relay log 已写满但 SQL 没跟上，延迟集中在第三段（回放）
为什么开并行复制前要先 stop slave
MySQL 的并行复制参数（如 slave_parallel_workers、slave_parallel_type）是只读变量，必须在复制停止状态下才能修改。强行在线改会报错：ERROR 1238 (HY000): Variable 'slave_parallel_workers' is a read only variable。
实操顺序不能错：
stop slave;-
set global slave_parallel_type = 'logical_clock';（5.7+ 推荐，按逻辑时间戳分组并发） -
set global slave_parallel_workers = 4;（建议从 2~4 开始试，别盲目设成 CPU 核数） start slave;
改完立刻查 show processlist;，能看到多个 Worker 线程，说明生效了。
开了并行复制还是慢？检查 relay log 写盘瓶颈
并行复制只是加速 SQL 回放，但 relay log 的磁盘写入仍由单个 IO 线程完成。如果从库磁盘 IOPS 不足、relay log 目录所在分区空间紧张或刷盘太频繁，IO 线程本身就会拖后腿。
验证方法：
- 看
Relay_Log_Space值是否持续增长（比如 > 2GB），结合df -h查 relay log 所在分区剩余空间 - 查系统 iostat：若
%util接近 100% 且await> 20ms，说明磁盘已饱和 - 确认
relay_log_space_limit是否过小（默认 0，不限制），避免因空间不足触发 IO 线程频繁 flush
临时缓解可调大 relay_log_space_limit，但根治得换 SSD 或把 relay log 单独挂到高速盘。
大事务导致并行失效的典型表现
哪怕开了 logical_clock 并行模式，只要主库有未提交的大事务（比如批量 UPDATE 百万行、ALTER TABLE 加索引），从库 SQL 线程组也会被强制串行等待——因为所有子事件必须按原事务顺序提交，无法拆分。
快速定位方式：
-
select * from information_schema.innodb_trx order by trx_started limit 5;看trx_rows_modified是否超 10 万 -
show engine innodb status\G中找TRANSACTIONS段，关注长时间RUNNING的事务 - 解析 relay log：
mysqlbinlog --base64-output=decode-rows -vv mysql-relay-bin.000001 | grep -A 5 -B 5 "### INSERT" | head -20，观察单条事件影响行数
这类事务没法靠调参解决，只能让业务拆分或避开高峰期执行。
