必须显式授予 GRANT SELECT ON performance_schema.，因为 performance_schema 不继承全局权限，.* 无效，且仅支持库级通配授权，单表授权或 host 不匹配均失败。
直接给 SELECT 权限到 performance_schema 库即可，但必须用 GRANT SELECT ON performance_schema.* 显式授权，不能靠全局权限或 USAGE 代替。
为什么 GRANT SELECT ON *.* 不管用
MySQL 的 performance_schema 是一个特殊系统库，它不遵循常规权限继承规则。即使用户有 SELECT 全局权限（*.*），默认也无法查询其中任何表：
-
performance_schema表的访问控制独立于mysql.user中的全局权限字段 -
SHOW DATABASES也不会列出performance_schema，除非显式授予其SELECT - 执行
SELECT * FROM performance_schema.events_statements_summary_by_digest会报错：ERROR 1142 (42000): SELECT command denied to user
正确授权命令与注意事项
必须用精确的库级授权语法，并注意 MySQL 版本差异：
- MySQL 5.7+ 和 8.0 均支持：
GRANT SELECT ON performance_schema.* TO 'monitor'@'localhost'; - 不能写成
GRANT SELECT ON performance_schema.events_waits_current—— 单表授权无效，必须是performance_schema.* - 授权后需执行
FLUSH PRIVILEGES;（仅在直接改表后才必需；用GRANT语句通常自动生效） - 如果用户连接 host 是
'monitor'@'192.168.5.10'，授权时 host 必须完全匹配，不能只写'%'而忽略实际连接来源
验证是否生效的三步检查
别只看 SHOW GRANTS，要实测 + 查元数据：
- 用目标用户登录后执行：
SHOW DATABASES;—— 确认performance_schema出现在列表中 - 执行：
USE performance_schema; SHOW TABLES LIMIT 1;—— 验证能否进入并列出表 - 查权限记录：
SELECT COUNT(*) FROM information_schema.role_table_grants WHERE table_schema = 'performance_schema';（若为空，说明没授成功）
最容易被忽略的是 host 匹配和误以为 *.* 能覆盖系统库——performance_schema 必须单独、显式授权，且只接受 .* 形式，不接受通配表名或省略。
