Performance Schema 默认启用但关键监控需手动开启instruments和consumers；验证需检查引擎支持、表可访问性；语句监控需启用对应采集器并调大history大小；查慢查询需结合等待事件、IO统计及指纹聚合分析。
Performance Schema 默认在 MySQL 5.7+ 已启用，但多数关键监控项（如语句历史、等待事件）默认是关闭的——光靠 performance_schema=ON 不够，必须手动打开对应的 instruments 和 consumers。
确认 performance_schema 是否真正可用
只查 SHOW VARIABLES LIKE 'performance_schema' 返回 ON 并不能说明能用。真正要验证的是：
- 引擎是否加载成功：执行
SHOW ENGINES，确认PERFORMANCE_SCHEMA行的Support值为YES - 能否访问表：运行
USE performance_schema; SHOW TABLES LIMIT 5;，若报错Unknown database 'performance_schema'或空结果，说明未启用或权限不足 - 注意：某些云数据库（如 RDS MySQL 基础版）明确不支持，
SHOW ENGINES中直接没有该引擎
开启语句级监控（events_statements_* 系列）
默认情况下，events_statements_history 这类表有数据但全是空的，因为采集器被关了。必须显式启用：
- 先查当前状态：
SELECT NAME, ENABLED, TIMED FROM performance_schema.setup_instruments WHERE NAME LIKE 'statement/%' AND NAME NOT LIKE '%abstract%'; - 批量启用（推荐）：
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_summary_by_digest'); - ⚠️ 注意：这些修改仅在当前实例生命周期内有效；重启后需重新执行，或写入配置文件并配合启动参数固化
调整 history 表大小避免数据被快速覆盖
events_statements_history 默认每线程只存 10 条，高并发下几乎查不到有用语句。不调大小，等于开了个摆设：
- 查看当前限制：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema_events_statements_history_size'; - 临时调大（例如设为 30）：
SET GLOBAL performance_schema_events_statements_history_size = 30; - 永久生效：在
my.cnf的[mysqld]段落下加一行：performance_schema_events_statements_history_size = 30 - ⚠️ 注意：增大该值会增加内存占用，且只对新连接生效；已有连接仍沿用旧值
查慢语句别只盯 events_statements_history
这个表只保留「最近执行完」的语句，但很多慢查询卡在锁、IO 或网络上，根本没走到“执行完成”阶段。真要抓瓶颈，得组合查：
- 等锁的语句：
SELECT * FROM performance_schema.events_waits_current WHERE EVENT_NAME LIKE 'wait/synch/mutex/%' OR EVENT_NAME LIKE 'wait/synch/cond/%'; - 磁盘 IO 瓶颈：
SELECT FILE_NAME, COUNT_READ, SUM_NUMBER_OF_BYTES_READ FROM performance_schema.file_summary_by_instance ORDER BY SUM_NUMBER_OF_BYTES_READ DESC LIMIT 5; - 按指纹聚合的耗时 Top 10：
SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 AS time_sec FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 10; - ⚠️ 注意：
DIGEST_TEXT可能被截断，且不包含注释和空格；若需完整 SQL，必须搭配events_statements_history_long（需额外启用对应 instrument）
真正难的不是开开关，而是理解哪些 instruments 对应什么行为、哪些 consumers 存什么数据、以及它们之间的内存开销权衡。比如开全 wait/io/file/% 在高 IO 场景下可能让性能下降 3%～5%，而很多人根本没意识到这点。
