真正能定位慢SQL的是performance_schema.events_statements_summary_by_digest，它按SQL模板聚合统计，含avg_timer_wait、sum_rows_examined等关键字段；events_statements_history仅存最近快照，无排序、无索引信息、易覆盖，不能替代。
events_statements_history 不是用来排查慢 SQL 的有效工具，它记录的是最近执行过的语句（默认仅 10000 行），且不带执行耗时排序、无索引使用信息、不记录扫描行数，**不能替代慢查询日志或 performance_schema.events_statements_summary_by_digest**。
真正能定位慢 SQL 的，是 performance_schema.events_statements_summary_by_digest —— 它按 SQL 模板聚合统计，自带 avg_timer_wait、sum_rows_examined、digest_text 等关键字段，才是性能分析的起点。
为什么不能依赖 events_statements_history
这个表本质是“最近执行快照”，不是“慢 SQL 归档”：
-
events_statements_history默认只保留每个线程最近 10 条语句（由performance_schema_events_statements_history_size控制），全局总量受performance_schema_events_statements_history_long_size限制，极易被覆盖 - 没有
rows_examined字段（MySQL 8.0+ 才在events_statements_summary_by_digest中稳定提供），无法判断是否全表扫描 - 时间字段
timer_wait单位是皮秒，需手动换算，且未归一化，没法直接排序找“最慢的 10 条” - 不区分用户、数据库、是否命中索引，缺乏上下文，查到一条慢语句也难复现或归因
该用哪个表？优先查 events_statements_summary_by_digest
这才是 performance_schema 中真正用于慢 SQL 分析的聚合视图，字段完整、可排序、支持过滤：
- 用
avg_timer_wait排序，找平均耗时最高的 SQL 模板：SELECT digest_text, avg_timer_wait/1000000000 AS avg_time_s, sum_rows_examined, count_star FROM performance_schema.events_statements_summary_by_digest ORDER BY avg_timer_wait DESC LIMIT 10;
- 加条件筛出高扫描行数语句：
WHERE sum_rows_examined > 10000 - 排除系统语句干扰：
AND digest_text NOT LIKE 'SELECT @@%' - 注意：该表默认开启，但需确保
consumers已启用：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'statements_digest';
events_statements_history 唯一可用场景：现场抓取刚跑完的可疑语句
仅适用于 DBA 在问题发生的“当下”连接上去，快速看某线程刚执行了什么（比如应用报错后立刻连上去查）：
- 必须先知道线程 ID（如从
processlist或错误日志中获取），再查：SELECT sql_text, timer_wait/1000000000 AS time_s, rows_examined FROM performance_schema.events_statements_history WHERE thread_id = 12345 ORDER BY event_id DESC LIMIT 5;
- MySQL 5.7 不提供
rows_examined，8.0+ 才有；若字段为空，说明没采集到或该语句未走 optimizer tracing 路径 - 查不到？大概率已被循环覆盖，或该线程未启用 instrumentation（检查
setup_threads中对应线程的INSTRUMENTED是否为 YES）
别忘了基础配置：慢查询日志仍是主力
performance_schema 是内存采样，重启清空、容量有限；而慢查询日志（slow_query_log）是磁盘持久化、带完整上下文，仍是生产环境第一道防线：
- 确认已开启：
SHOW VARIABLES LIKE 'slow_query_log';应为ON - 阈值别设太高：
long_query_time = 1（非默认 10），核心服务可压到0.5 - 务必关掉
log_queries_not_using_indexes（除非临时做索引审计），否则小表全扫也会刷爆磁盘 - 日志分析用
mysqldumpslow -s t -t 10 /var/lib/mysql/mysql-slow.log，比手动翻文件快得多
events_statements_history 里反复翻页，它不是设计来干这事的。聚合视图 + 慢日志 + EXPLAIN 三者配合，才构成闭环。字段缺失、阈值误配、consumer 未开——这些细节比语法本身更容易让人卡住。 
