Performance Schema 默认关闭，需在my.cnf中设performance_schema=ON并重启；启用语句和阶段事件采集、限制监控范围才能高效定位慢SQL。
Performance Schema 默认是关闭的，必须手动启用才能采集数据
MySQL 5.6+ 虽然默认编译了 Performance Schema，但performance_schema系统变量默认为OFF，启动后也不会自动收集任何事件。不启用就查不到events_statements_history_long或events_waits_current里的任何记录。
启用方式很简单，但必须在 MySQL 启动前配置（或重启后生效）：
- 在
my.cnf的[mysqld]段落中添加：performance_schema=ON - 同时建议开启关键消费者表：
performance_schema_events_statements_history_long_consumers=ON（否则events_statements_history_long为空） - 如果只关心 SQL 执行耗时，至少要打开语句事件采集：
performance_schema_setup_instruments='statement/sql/%=ON'
注意：修改配置后必须重启 MySQL，SET PERSIST performance_schema=ON 不生效——这不是运行时可调参数。
查慢 SQL 不能只看 events_statements_history_long，得配对查 events_stages_history_long
events_statements_history_long 只记录 SQL 文本、执行时间、影响行数等顶层信息，但无法告诉你“为什么慢”。真正定位瓶颈得看它内部各阶段耗时，比如 parsing、optimizing、executing、locking、sending data 等。
每个语句在events_statements_history_long中有一条记录，其EVENT_ID对应events_stages_history_long中以该EVENT_ID为NESTING_EVENT_ID的所有阶段记录。典型查询逻辑是：
SELECT s.SQL_TEXT, s.TIMER_WAIT/1000000000 AS sec,
st.STAGE, st.TIMER_WAIT/1000000000 AS stage_sec
FROM performance_schema.events_statements_history_long s
JOIN performance_schema.events_stages_history_long st
ON st.NESTING_EVENT_ID = s.EVENT_ID
WHERE s.SQL_TEXT LIKE '%UPDATE orders%'
ORDER BY s.TIMER_WAIT DESC LIMIT 5;常见陷阱：events_stages_history_long默认不开启 stage 级采集，需额外启用 instrument：performance_schema_setup_instruments='stage/%=ON'，否则 stage 表全空。
setup_actors 和 setup_objects 控制采集粒度，别让监控拖垮线上库
Performance Schema 默认采集所有用户、所有库表的操作，高并发下会产生大量事件写入内存，可能引发性能抖动甚至 OOM。必须按需收缩范围：
- 用
setup_actors限制只监控特定用户：INSERT INTO performance_schema.setup_actors VALUES ('%', 'admin', '%', 'YES', 'YES', 'YES') - 用
setup_objects限制只监控关键表：INSERT INTO performance_schema.setup_objects VALUES ('TABLE','test','t_order','YES','YES') - 禁用无关 instrument（如 file I/O、network）：
UPDATE performance_schema.setup_instruments SET ENABLED='NO' WHERE NAME LIKE 'wait/io/file/%'
特别注意：setup_actors 修改后立即生效，无需重启；但已存在的连接不会被 retroactively 追踪，新连接才受控。
用 sys.schema_table_statistics 快速定位热点表，但别直接依赖它的 total_latency
sys 库下的视图是对 Performance Schema 的封装，sys.schema_table_statistics 能快速看到各表的读写次数和总延迟，适合初步排查。但它底层依赖 events_statements_summary_by_digest 和 events_waits_summary_global_by_event_name，而这两张表默认只聚合 digest（即去参数化后的 SQL 模板），丢失具体条件。
例如：SELECT * FROM users WHERE id = ? 和 SELECT * FROM users WHERE id = 12345 在 digest 层面合并为同一条，total_latency 是平均值，不是单次执行耗时。真要分析某次异常执行，必须回到 events_statements_history_long 查原始记录 + THREAD_ID 关联上下文。
另外，sys 视图本身有开销，频繁查询会触发内部聚合计算，生产环境慎用 sys.statement_analysis 这类重型视图。
