最小权限为SELECT + USAGE：SELECT用于查询performance_schema只读表，USAGE用于允许连接并使库可见；仅授SELECT会导致Access denied，因MySQL 8.0+默认隐藏该库。
只读性能视图需要哪些最小权限？
MySQL 的 performance_schema 默认对普通用户不可见，即使你只查 events_statements_summary_by_digest 这类只读表，也必须显式授权。核心权限只有两个：SELECT 权限 + USAGE 权限（后者用于允许连接，常被忽略）。
常见错误是只授 SELECT 却忘了 performance_schema 库本身要先被“看到”——MySQL 8.0+ 默认关闭了 performance_schema 对非 super 用户的自动可见性，所以 USAGE 是必需的。
如何创建监控账号并授极简权限？
执行以下语句（替换 mon_user 和 '192.168.1.%' 为实际用户名和来源 IP）：
CREATE USER 'mon_user'@'192.168.1.%' IDENTIFIED BY 'strong_password'; GRANT USAGE ON *.* TO 'mon_user'@'192.168.1.%'; GRANT SELECT ON performance_schema.* TO 'mon_user'@'192.168.1.%'; FLUSH PRIVILEGES;
注意三点：
-
USAGE ON *.*不是冗余操作，它让账号能成功建立连接（否则会报Access denied for user，哪怕SELECT已授） - 不要授
SELECT ON *.*或SELECT ON information_schema.*—— 监控组件通常不需要元数据全量读取，且information_schema中部分表（如PROCESSLIST）可能暴露敏感会话信息 - MySQL 8.0.16+ 若启用了
activate_all_roles_on_login，需确认该账号无隐式角色继承高权限
验证权限是否生效？
用监控账号登录后，执行：
SELECT COUNT(*) FROM performance_schema.events_statements_summary_by_digest LIMIT 1;
如果返回数字，说明权限到位；若报错 Table 'performance_schema.events_statements_summary_by_digest' doesn't exist，大概率是账号没被授予 USAGE；若报错 SELECT command denied，则是 SELECT 权限未落到 performance_schema 库上。
额外检查点：
- 确保 MySQL 启动时未禁用
performance_schema（performance_schema=ON必须在 my.cnf 中显式设置） - 某些旧版监控工具（如早期 Prometheus mysqld_exporter）会尝试查
setup_*表来判断功能开关，这些表也属于performance_schema，所以授整个库比单表更稳妥 - 避免使用
SHOW PROCESSLIST—— 它依赖PROCESS权限，不属于极简范畴，应改用performance_schema.threads替代
为什么不用 role 或 proxy user？
MySQL 的 ROLE 在 5.7 不支持，8.0 虽支持但引入额外管理复杂度；PROXY USER 则要求客户端明确声明代理关系，多数监控组件不支持。直接建专用账号 + 极简权限组合，部署快、排查链路短、审计清晰。
真正容易被忽略的是：MySQL 重启后，若 performance_schema 因配置缺失被自动关闭，所有基于它的查询都会静默失败——务必把 performance_schema=ON 写死在配置文件里，而不是依赖默认值。
