最快定位从库慢语句的方法是执行show full processlist，重点关注command为query、time超阈值、state为executing或sending data的行；其次可用performance_schema.events_statements_history_long查sql_thread最近高耗时语句。
直接查从库正在执行的慢语句
主从延迟时，最急迫的问题是“现在卡在哪条 SQL 上”。SHOW FULL PROCESSLIST 是最快响应的手段，不需要任何前置配置，5 秒内就能看到正在回放、且已卡住的语句。
重点关注 Command 为 Query、Time 大于业务容忍阈值（比如 3 秒）、State 为 executing 或 sending data 的行。这些就是正在拖慢复制进度的“现行犯”。
-
Id字段可直接用于KILL中断（谨慎操作，确认非关键事务） -
User和Host能帮你判断是否来自特定应用或中间件 -
Info列就是完整 SQL，复制出来就能立刻用EXPLAIN分析
用 Performance Schema 抓取最近的高耗时语句
如果慢 SQL 已执行完但没进慢日志（比如 long_query_time 设得太高），performance_schema.events_statements_history_long 就是兜底方案。它默认开启，记录最近约 1 万条语句的实际耗时。
执行这条查询能快速筛出复制线程（SQL_THREAD）执行过的最慢几条：
SELECT DIGEST_TEXT, TIMER_WAIT/1000000000 AS time_sec, ROWS_AFFECTED FROM performance_schema.events_statements_history_long WHERE THREAD_ID IN ( SELECT THREAD_ID FROM performance_schema.threads WHERE NAME = 'thread/sql/slave_sql' ) ORDER BY TIMER_WAIT DESC LIMIT 5;
注意：TIMER_WAIT 单位是纳秒，除以 1e9 才是秒；DIGEST_TEXT 是归一化后的 SQL 模板，便于识别重复模式。
分析慢 SQL 为什么在从库更慢
同一条 SQL 在主库快、从库慢，常见原因不是 SQL 本身，而是执行上下文不同。重点排查这几点：
- 从库
innodb_buffer_pool_size设置过小，导致大量磁盘读 —— 查SHOW ENGINE INNODB STATUS里的Buffer pool hit rate - 从库开了
log_slave_updates=1，又没关binlog_format=ROW下的冗余写入开销 - SQL 里含
UUID()、NOW()等非确定性函数，触发从库重算或锁等待 - 主库用了并行写入（如
binlog_group_commit_sync_delay），但从库单线程回放，放大了单条耗时
别只看 EXPLAIN 结果 —— 它反映的是主库的执行计划。从库上要连带查 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS，确认有没有被其他事务阻塞。
避免误判：Seconds_Behind_Master 不等于 SQL 执行时间
Seconds_Behind_Master 是估算值，受 relay_log 写入延迟、网络抖动、甚至系统时间不同步影响。它可能突然跳变，也可能长时间卡在 0 却实际有慢 SQL 正在执行（比如 State 是 Waiting for an event from Coordinator）。
真正可靠的信号是：
-
Exec_Master_Log_Pos停滞不动，而Read_Master_Log_Pos持续前进 → IO 线程正常，SQL 线程卡死 -
Relay_Log_Space持续上涨 → relay log 积压，SQL 回放跟不上 -
Slave_SQL_Running_State显示Reading event from the relay log以外的状态（如Updating、Copying to tmp table）→ 正在执行某条重负载语句
定位到具体 SQL 后，优先检查它在从库是否走了索引、是否触发了 Using temporary 或 Using filesort —— 这些在从库资源受限时会比主库更致命。
