performance_schema默认不监控线程因开销大，需手动启用consumers和instruments；8.0.26+才默认采集复制语句，旧版本需依赖replication_applier_status_by_worker等表定位。
performance_schema 为什么默认不监控线程？
因为开销。MySQL 启动时 performance_schema 默认启用，但多数线程相关表（比如 events_statements_history_long、threads）的采集开关是关的——不是功能没加载，是数据根本没写进去。
实操建议：
- 先确认是否真开了线程监控：
SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE '%thread%';
如果ENABLED是NO，光查threads表只会看到空或极少量记录 - 必须同时打开消费者和仪器：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_current', 'events_statements_history_long', 'events_waits_current');<br>UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/%' OR NAME LIKE 'wait/%'; - 别在生产库直接开全量
statement采集，尤其高并发从库——events_statements_history_long默认只存 10000 行，刷得快会丢历史，且内存占用明显上升
从库线程卡在哪？重点盯这三个表
主从延迟不是“慢”，而是某类操作在阻塞 SQL 线程或 IO 线程。别只看 SHOW SLAVE STATUS 的 Seconds_Behind_Master，它可能为 0 但实际积压已发生。
实操建议：
-
performance_schema.threads：找 SQL 线程 ID（NAME含thread/sql/slave_sql），记下它的THREAD_ID -
performance_schema.events_waits_current：用上一步的THREAD_ID查当前等待事件，常见卡点：wait/io/file/innodb/innodb_data_file（磁盘 IO）、wait/synch/mutex/innodb/trx_sys_mutex（事务锁竞争）、wait/io/socket/sql/client_connection（极少，说明线程异常） -
performance_schema.events_statements_current：同理查该线程正在执行哪条语句，注意SQL_TEXT可能被截断，要配合digest_text看模式（如全是INSERT INTO t1 ... SELECT ...）
为什么开了 performance_schema 还看不到从库的复制语句？
因为 MySQL 8.0.26+ 才把复制线程的语句默认纳入 events_statements_*；旧版本（如 5.7、8.0.22）即使开了采集，slave_sql 线程的语句也不会进 events_statements_current，只能靠 events_waits_current 和 replication_applier_status_by_worker 推断。
实操建议：
- 先查版本：
SELECT VERSION();
若低于 8.0.26，别浪费时间在events_statements_*上找复制 SQL - 降级方案：用
SELECT * FROM performance_schema.replication_applier_status_by_worker;看LAST_APPLIED_TRANSACTION和APPLYING_TRANSACTION，再结合binlog_events（需开启log_bin并有权限）定位具体语句 - 注意
replication_applier_status_by_worker中WORKER_ID为NULL表示单线程模式，此时只有一行；多线程下每行对应一个 worker，要逐个查其等待事件
采样频率太高反而掩盖瓶颈？
不是所有等待都值得记。比如 wait/io/file/myisam/kfile 单次耗时几微秒，每秒几千次，开着 TIMED = YES 会吃掉大量内存和 CPU，却对定位“为什么大事务卡住 30 秒”毫无帮助。
实操建议：
- 优先打开
TIMED = YES给长耗时类仪器，例如：UPDATE performance_schema.setup_instruments SET TIMED = 'YES' WHERE NAME IN ('wait/synch/mutex/innodb/%', 'wait/io/file/innodb/innodb_data_file'); - 对高频短事件（如
wait/synch/rwlock/innodb/%），可设TIMED = NO，只统计次数，避免性能干扰 - 临时诊断时，用
events_waits_history_long替代events_waits_current，它保留最近 10000 次等待（含超时），更容易抓到偶发长等待
真正卡住从库的，往往不是平均响应时间，而是某次锁等待突然飙到秒级，或者某个大事务触发了 buffer pool 大量刷脏。这些细节藏在单次事件里，而不是聚合指标中。
