SQL线程在从库中负责重放中继日志中的事务以实现主从数据同步；执行时可见于SHOW PROCESSLIST中User为system user、State为executing或Waiting for...的记录，Info字段显示当前执行语句。
show processlist 能看到从库 SQL 线程正在执行什么
SHOW PROCESSLIST 在从库上执行，能直接看到 SQL Thread 当前正在重放哪条语句。它不是在“查状态”，而是在“抓现场”——只要 Slave_SQL_Running_State 显示为 Reading event from the relay log 或 Executing event，那 PROCESSLIST 里就大概率有一行 State 为 executing（或类似）且 User 为 system user 的记录，对应的就是正在跑的复制语句。
- 这行记录的
Time值如果持续增长（比如从 5 秒涨到 120 秒），基本可判定该语句就是延迟源头 -
Info字段会显示完整 SQL（除非被截断），重点关注是否含UPDATE/DELETE+ 大范围WHERE、INSERT ... SELECT、ALTER TABLE或带GROUP BY/ORDER BY的子查询 - 如果
Info是空，但State长时间卡在Waiting for dependent transaction to commit，说明主库有未提交的大事务，或从库遇到锁冲突（如被其它SELECT ... FOR UPDATE持有行锁）
为什么不能只看 Seconds_Behind_Master
Seconds_Behind_Master 是个“估算值”，不是精确延迟。它依赖主从服务器时间一致，且只反映 relay log 中最后一个 event 的时间戳与当前从库系统时间的差值。一旦出现以下情况，这个值就失效：
- 主库时间快于从库（比如快 3 分钟），
Seconds_Behind_Master可能长期显示 180+，但实际没延迟 - 主库刚提交一个大事务，relay log 还没写完，
Seconds_Behind_Master仍为 0，但 SQL 线程已积压 - 使用
MIXED或STATEMENT格式时，某些函数（如NOW()、UUID()）导致从库执行逻辑不同，SBM完全不可信
真正可靠的是：
-
Relay_Master_Log_File和Exec_Master_Log_Pos是否追平Master_Log_File和Read_Master_Log_Pos -
Slave_SQL_Running_State的实时内容 -
SHOW PROCESSLIST中 system user 的活跃 SQL
SQL 线程慢的典型语句特征
从库 SQL 线程是单线程串行执行 relay log 里的 event，所以哪怕一条语句慢，整个复制就卡住。常见高危模式包括：
UPDATE t SET status = 1 WHERE create_time ：没走索引，全表扫描更新百万行-
INSERT INTO report_log SELECT ... FROM orders JOIN order_items ... GROUP BY date：涉及多表 JOIN + 聚合，临时表 + filesort -
ALTER TABLE users ENGINE=InnoDB：DDL 在 RBR 模式下会转成逐行 INSERT/DELETE，日志量爆炸 DELETE FROM logs WHERE ts ：函数包裹索引列，索引失效，又无 LIMIT 分批
这类语句在主库可能因并发写入不明显，但从库 SQL 线程必须等它执行完才能继续，延迟立刻累积。
排查时容易忽略的两个点
第一，SHOW PROCESSLIST 默认只显示前 100 个字符的 Info，大 SQL 直接被截断。必须加 pager grep -v Sleep 或用 SELECT * FROM information_schema.PROCESSLIST WHERE USER = 'system user'\G 查完整语句。
第二，别只盯着 State = executing。如果看到 State = Waiting for table metadata lock，说明有 DDL 正在等待 MDL 锁——很可能是主库刚执行了 ALTER TABLE，而从库上还有长事务没释放读锁，此时得去 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS 查阻塞链。
真实延迟往往不在 SQL 本身，而在它前面那个没结束的事务。
