三个线程各干什么
传统异步复制里从库有两个关键线程：IO 线程负责连主库、拉 binlog 并写进 relay log；SQL 线程负责把 relay log 里的事件重放成数据变更。线程状态字符串就是诊断语言，同一个状态在不同上下文含义完全不同，比如 Waiting for source to send event 在 IO 线程是正常待命，在 SQL 线程则说明 relay log 已清空。
基本信息
| 适用 | MySQL 5.7 / 8.0（8.0 术语为 source / replica） |
|---|---|
| 查看入口 | SHOW PROCESSLIST 与 SHOW REPLICA STATUS |
| 关键列 | Replica_IO_State、Replica_SQL_Running_State、Seconds_Behind_Source |
| 并行复制 | performance_schema.replication_applier_status_by_worker 看每个 worker |
状态对照与判断
| 线程 | 状态文本 | 含义 |
|---|---|---|
| IO | Waiting for source to send event | 正常待命，没有新事件可拉 |
| IO | Connecting to source | 网络断连重试中，查 Last_IO_Error |
| IO | Queueing source event to the relay log | 正在拉取并写入 relay log |
| SQL | Reading event from the relay log | 正在重放，属正常工作状态 |
| SQL | Waiting for a handler to become available | 等表锁或元数据锁，可能被慢查询阻塞 |
| SQL | Waiting for source to send event 且空闲 | relay 已清空，复制追平 |
查看线程状态
查看线程状态
SHOW PROCESSLIST; # 从库上会看到 system user 的 IO / SQL 线程
SHOW REPLICA STATUS\G # Replica_IO_State 与 Replica_SQL_Running_State
SELECT THREAD_ID, SERVICE_STATE FROM performance_schema.replication_applier_status_by_worker; # 并行 worker 逐个看
SELECT * FROM performance_schema.replication_connection_status\G # IO 侧连接与队列状态
SHOW STATUS LIKE 'Slave_open_temp_tables'; # 5.7 术语下检查临时表残留典型使用场景
- 从库延迟告警，先区分是 IO 拉不到还是 SQL 重放慢，再决定优化方向
- 主从断连后确认线程是否自动重连，还是已经停止需要人工介入
- 并行复制调优，观察 worker 是否长期空闲说明并行度设置过高
- 发布大事务后观察 relay log 消耗速度，判断是否要限制批量窗口
- 故障切换前核对从库状态与延迟，避免把滞后节点提升为主
IO 显示 Connecting 时优先看 Last_IO_Error，再查网络连通性、防火墙策略与复制账号来源主机限制，三者覆盖绝大多数场景。
SQL 线程长期等锁会让 relay log 持续堆积直至磁盘告警：发现 Waiting for a handler 要先找出持锁来源，而不是直接重启从库。
从库延迟排查顺序
- 先看 Replica_IO_Running 与 Replica_SQL_Running，任一为 No 就是线程停了，不是延迟问题
- 两者都为 Yes 再看 Replica_IO_State，长期 Connecting 说明网络或认证异常
- SQL 侧持续 Reading event 且延迟不降，多为大事务重放或并行度不足
- relay log 持续增大说明拉取快于重放，反压已经形成，优先处理重放瓶颈
- 最后核对从库是否被业务当读库使用，读写混部会放大锁冲突与延迟