mysql普通用户无法查看performance_schema信息，因5.7+默认禁止访问，须显式授权select on performance_schema.*或具体表，并启用instruments和consumers才能查到数据。
GRANT SELECT ON performance_schema.* 不生效？必须显式授权
直接执行 GRANT SELECT ON performance_schema.* TO 'u1'@'%' 看似合理，但常被忽略的关键点是：MySQL 不允许用 ALL PRIVILEGES 或通配符授权覆盖 performance_schema —— 即使你是 root，运行 GRANT ALL ON performance_schema.* TO ... 也会报错 ERROR 1044 (42000)。它不被视为普通数据库，而是受特殊权限模型约束的系统库。
正确做法是逐表或按需批量授权：
- 只查 SQL 摘要：至少授
events_statements_summary_by_digest、events_statements_current、setup_consumers - 查线程状态：加
threads；若需processlist，确认 MySQL ≥ 8.0.14 且用户有PROCESS权限（非仅 SELECT） - 避免过度授权：像
mutex_instances、rwlock_instances等表即使授了SELECT，普通用户也查不到数据，因为底层依赖SUPER或PROCESS
开了 SELECT 权限还是查不到数据？检查 instruments 和 consumers
授完权 ≠ 能看到数据。performance_schema 是“按需采集”，默认只启用极少数 instrument（如仅 statement/sql/select），且大部分 consumers 默认关闭。用户执行 SELECT * FROM events_statements_summary_by_digest 返回空，大概率是这两个环节没开：
- 确认采集开关：查
performance_schema.setup_instruments，对应 instrument 的ENABLED和Timed都得是YES（例如查慢 SQL 要开statement/sql/insert、statement/sql/update） - 确认汇总开关：查
performance_schema.setup_consumers，确保events_statements_current、events_statements_summary_by_digest对应行的ENABLED为YES - 动态开启（无需重启）：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/sql/%';
MySQL 8.0+ 还要留意 show_compatibility_56=OFF
MySQL 8.0 默认关闭兼容模式，视图名与 5.6/5.7 不一致。比如旧版叫 events_statements_summary_by_digest，开启 show_compatibility_56=ON 后可能映射为 events_statements_summary_by_digest_long 等别名。但该变量本身已被标记为 deprecated，官方强烈建议保持 OFF（默认值）。
如果你在 8.0+ 上遇到视图不存在错误，先确认：
-
SHOW VARIABLES LIKE 'show_compatibility_56';—— 应返回OFF -
SHOW TABLES IN performance_schema LIKE 'events%digest%';—— 直接看真实表名 - 不要依赖文档中 5.7 的视图名照搬使用，8.0 的视图结构更细、命名更统一
FLUSH PRIVILEGES 不可省，尤其跨版本或跳过 grant tables 启动后
权限变更后必须执行 FLUSH PRIVILEGES，否则新授权不会加载进内存。这个动作在以下场景尤为关键：
- MySQL 5.7 升级到 8.0 后首次授权（旧权限缓存未刷新）
- 使用
--skip-grant-tables启动后手动修改了mysql.user表 - 通过配置文件修改了
my.cnf中的权限相关参数（极少见，但存在）
注意：FLUSH PRIVILEGES 不会重载 performance_schema 的 instruments/consumers 配置，那部分需单独更新 setup_* 表或重启 mysqld。
真正容易被忽略的是：你改了 setup_consumers，却忘了用户根本没 SELECT 权限去查那个表——所以先授表权，再调配置，顺序不能反。
