Performance Schema 默认启用但关键采集项关闭，需检查 instruments 和 consumers 是否启用，并合理配置 history 大小与 digest 长度，否则数据稀疏或截断。
Performance Schema 默认已启用，但多数关键采集项是关闭的——直接查 performance_schema 表会发现几乎全是空的，这不是没开，而是“开了但没采”。
检查是否真正在工作
只看 SHOW VARIABLES LIKE 'performance_schema' 返回 ON 不够。真正要确认的是：仪器（instruments）有没有开、消费者（consumers）有没有存。
- 运行
SELECT COUNT(*) FROM performance_schema.setup_instruments WHERE ENABLED = 'YES' AND NAME LIKE 'statement/%'—— 如果结果是 0，说明 SQL 执行事件根本没采集 - 运行
SELECT * FROM performance_schema.setup_consumers WHERE ENABLED = 'YES'—— 至少要看到events_statements_current、events_statements_history这类 consumer 是YES - 如果
setup_instruments里大量wait/%或statement/%行的ENABLED是NO，那 Performance Schema 就等于“开机不点火”
启动时配置 vs 运行时配置
MySQL 重启后，setup_instruments 和 setup_consumers 表会重置为默认值（多数 OFF）。所以必须区分两种配置方式：
- 持久化配置写进
my.cnf：performance_schema = ON是基础，但光这一行远远不够 - 真正控制采集粒度的是启动参数，比如：
--performance-schema-instrument='statement/sql/select=ON'，或批量启用：--performance-schema-instrument='statement/%=ON' - 运行时用
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'statement/%'可临时生效，但 MySQL 一重启就丢 -
performance_schema_max_digest_length、performance_schema_events_statements_history_size这类系统变量必须在my.cnf里设，否则启动时内存分配不足，后续查events_statements_summary_by_digest会截断 SQL
哪些 instrument 真正值得开
全开 statement/% 和 wait/% 在高并发下可能吃掉 5–10% CPU，没必要。按需打开更稳妥：
- 查慢查询根因：开
statement/%+wait/synch/mutex/%+wait/io/file/% - 定位锁等待：必须开
wait/synch/cond/%和wait/synch/mutex/%，否则events_waits_current里看不到锁链 - 分析存储过程性能：除了
statement/%，还得开sp/%类 instrument（如sp/sp_instr_stmt），否则过程内语句不计入统计 - 注意
memory/performance_schema/%类 instrument 是硬编码内置的，不能通过setup_instruments关闭，但它们本身不产生额外开销
容易被忽略的内存和大小限制
Performance Schema 数据全存在内存里，配得小了，刚想查历史就发现表里只有最后几条记录：
-
performance_schema_events_statements_history_size控制每个线程保留多少条最近语句，默认仅 10 —— 查不到历史？先调到 20 或 30 -
performance_schema_events_statements_history_long_size控制全局长历史，默认 10000，但若语句多、执行快，这点容量撑不过几分钟 -
performance_schema_max_digest_length默认 1024 字节，遇到带长 JSON 或大批量 INSERT 的语句，DIGEST_TEXT直接被截断，看不出真实模式 - 改这些值必须重启 MySQL，且总内存占用 ≈ 各 history size × 单条记录大小 × 并发线程数，别盲目往大调
最常踩的坑不是“没开”，而是开了却没配 instrument、没调 history 大小、没开对应 consumer——结果查 events_statements_summary_by_digest 发现数据稀疏，误以为没生效。盯住 setup_instruments 和 setup_consumers 两表的状态，比反复重启更省时间。
