MySQL 5.7+ 默认启用performance_schema，但SQL执行耗时、锁等待等关键采集项默认关闭，需手动启用setup_instruments中对应instrument及setup_consumers中相关consumer才能获取数据。
MySQL性能监控不是靠“安装客户端”就能开启的，它依赖服务端配置。默认情况下，MySQL 5.7+ 已启用 performance_schema，但很多关键采集项（比如SQL执行耗时、锁等待）是默认关闭的——你查不到数据，不等于没开，而是没配对。
确认 performance_schema 是否真正可用
先别急着改配置，先验证当前状态是否满足监控需求：
-
SHOW VARIABLES LIKE 'performance_schema';返回ON只说明模块加载了，不代表所有事件都在采集 - 执行
SELECT COUNT(*) FROM performance_schema.events_statements_summary_by_digest;，如果返回 0 或空结果，大概率是采集被禁用了 - 检查引擎支持：
SHOW ENGINES;中PERFORMANCE_SCHEMA的Support字段必须为YES
启用 SQL 执行与锁等待等关键采集项
performance_schema 默认只开基础线程和连接信息，真正有用的 SQL 耗时、锁等待、文件 IO 都需要手动打开：
- 登录 MySQL 后执行：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/sql/%'; - 启用锁相关采集：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME IN ('wait/lock/table/high_priority', 'wait/lock/table/low_priority', 'wait/lock/table/sql_handler'); - 重启不是必须的，这些是运行时生效的；但要注意：修改后需同时启用对应 consumer，例如：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%statements%';
为什么开了 performance_schema 还查不到慢查询？
因为 performance_schema 和 slow_query_log 是两套机制——前者记录所有语句（含快的），后者只录超阈值的。如果你只依赖 events_statements_summary_by_digest 却没看到预期的慢 SQL，常见原因有：
-
performance_schema_events_statements_history_size太小（默认 10），历史语句被快速覆盖，可调大该变量（需重启） - 应用使用连接池，短连接频繁创建销毁，
events_statements_history只存每个连接最近 N 条，旧连接的数据不可追溯 -
long_query_time在slow_query_log中设为 2，但performance_schema不认这个参数，它按实际TIMER_WAIT算，单位是皮秒（ps），记得除以1000000000000转成秒
真正要长期盯住慢查询，slow_query_log + mysqldumpslow 或 pt-query-digest 更可靠；performance_schema 更适合实时抓取、定位瞬时瓶颈。两者不是替代关系，而是互补——漏掉任何一个，都可能错过关键线索。
