查不到耗时数据是因为performance schema默认禁用statement instruments和consumers，需手动启用并设置timed=yes；耗时单位为皮秒，换算成秒需除以1e9；真瓶颈常在等待事件而非sql本身；存储过程和事务耗时需通过thread_id关联或启用transaction instrument追踪。
查不到耗时数据？先确认 instruments 和 consumers 都开了
直接查 events_statements_history_long 返回空，不是 MySQL 坏了，是默认关得比防火墙还严。5.7+ 默认把所有 statement/sql/ 类 instrument 设为 NO，events_statements_history_long 这类 consumer 也默认禁用。
必须手动执行两步：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/sql/%';UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_current', 'events_statements_history', 'events_statements_history_long', 'events_statements_summary_by_digest');
这两条语句只在当前会话生效；要永久启用，得在 my.cnf 加 performance_schema=ON 并重启。别漏掉 TIMED = 'YES'——没它，SUM_TIMER_WAIT 全是 0。
耗时单位是皮秒，别把 123456789000 当成 123 秒
SUM_TIMER_WAIT 和 TIMER_WAIT 的单位是皮秒（10⁻¹² 秒），不是毫秒也不是微秒。数值动辄上万亿，一眼看错就以为“这 SQL 跑了三天”。
换算成秒，统一除以 1e9（即 10⁹）：
SELECT DIGEST_TEXT, SUM_TIMER_WAIT / 1e9 AS sec FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;
注意：如果除以 1e6（微秒）或漏掉除法，结果会偏差 1000 倍。云数据库控制台里有些监控面板自动做了转换，但直接查表时你得自己扛。
慢的不是 SQL，是锁、IO 或内存分配
一条 SELECT 执行 2 秒，SQL_TEXT 本身可能只占 20ms——其余 1980ms 耗在等待上。这时候盯 events_statements_* 表只会误导。
真瓶颈往往藏在等待事件里：
- 查最烧时间的等待类型：
SELECT EVENT_NAME, SUM_TIMER_WAIT / 1e9 AS sec FROM performance_schema.events_waits_summary_global_by_event_name WHERE SUM_TIMER_WAIT > 0 ORDER BY SUM_TIMER_WAIT DESC LIMIT 5; - 常见高耗时项：
wait/io/file/innodb/innodb_log_file（刷 redo 日志）、wait/synch/mutex/innodb/trx_sys_mutex（事务系统争用）、wait/io/file/myisam/dfile（MyISAM 表扫描） - 若
wait/synch/cond/sql/COND_active_scheduler排前几，说明线程调度或连接池已饱和，不是 SQL 问题，是并发模型卡住了
存储过程和事务的耗时容易被拆散丢失
CALL proc_name() 在 events_statements_summary_by_digest 里只记一次调用耗时，但过程内几十条 INSERT、游标循环、临时表创建全被单独归类——你看到的是“一堆小 SQL”，找不到入口点。
要还原完整链路：
- 先查
EVENT_NAME = 'statement/sql/call'的原始记录：SELECT THREAD_ID, SQL_TEXT, TIMER_WAIT FROM performance_schema.events_statements_history_long WHERE EVENT_NAME = 'statement/sql/call' ORDER BY TIMER_WAIT DESC LIMIT 10; - 拿到
THREAD_ID后，关联performance_schema.threads确认用户、库、状态；再查同线程下后续的statement/sql/insert、statement/sql/select等事件，按EVENT_ID或NESTING_EVENT_ID排序还原执行流 - 事务级耗时需额外开
transactioninstrument：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'transaction';，然后查events_transactions_history_long
不连起来看，你就永远不知道那个“慢存储过程”到底是在等锁、刷盘，还是反复创建百万行临时表。
