show privileges 不包含 performance_schema 权限项，因其仅列出内置全局权限类型，不反映实际授权；需显式授予 select on performance_schema.* 才能查询性能表。
SHOW PRIVILEGES 返回的权限列表不包含 PERFORMANCE_SCHEMA 相关项？
因为 SHOW PRIVILEGES 只列出 MySQL 服务器**内置的全局权限类型**，不反映实际账号是否被授予、也不展示 performance_schema 库内具体表的细粒度权限。它告诉你“MySQL 支持哪些权限”，而不是“这个账号有啥权限”。真正决定能否做性能分析的是账号是否拥有 SELECT 权限（或 PROCESS、PROFILING 等）作用于 performance_schema 或 information_schema 中的特定表。
如何确认账号对 performance_schema 具备查询能力
直接查 performance_schema 的关键表，比如 events_statements_summary_by_digest，最可靠：
SELECT COUNT(*) FROM performance_schema.events_statements_summary_by_digest;
如果报错 ERROR 1142 (42000): SELECT command denied to user ... for table 'events_statements_summary_by_digest'，说明缺权限。此时应检查该账号在 mysql.tables_priv 或通过 SHOW GRANTS FOR 'user'@'host' 输出中是否有类似这样的记录：
GRANT SELECT ON performance_schema.* TO 'perf_user'@'%'GRANT SELECT ON performance_schema.events_statements_summary_by_digest TO 'perf_user'@'%'
注意：MySQL 8.0+ 默认关闭 performance_schema 表的隐式授权，即使有 SELECT on *，也需显式授给 performance_schema 库或具体表。
为什么给了 SELECT * 还查不了 performance_schema
这是最常见的坑。MySQL 的权限系统把 performance_schema 当作一个独立库处理，不继承 mysql 或普通业务库的通配授权。哪怕你执行过：
GRANT SELECT ON *.* TO 'user'@'%';
该语句也不会覆盖 performance_schema —— 它被 MySQL 视为“系统库”，必须单独授权。同理，information_schema 也一样。正确做法是补上：
GRANT SELECT ON performance_schema.* TO 'user'@'%';-
FLUSH PRIVILEGES;（仅当手动改了 mysql.tables_priv 才需要；用 GRANT 语句通常自动生效）
performance_schema 权限和 PROCESS/PROFILING 权限的区别
三者用途不同，容易混用：
-
PROCESS：用于SHOW PROCESSLIST和访问information_schema.PROCESSLIST，不涉及 performance_schema 表 -
PROFILING：控制是否能用SHOW PROFILES/SHOW PROFILE，只影响会话级 SQL 分析，且 MySQL 8.0 已弃用 -
SELECT ON performance_schema.*：才是读取所有性能指标（SQL 摘要、锁等待、IO 统计等）的必要条件
别指望开 PROCESS 就能查 events_waits_summary_global_by_event_name，它完全不搭界。
performance_schema 的权限粒度很细，但日常排查只要确保 SELECT 权限落在库或关键表上就行；真正容易漏掉的是——压根没意识到它需要单独授权，而不是随 *.* 自动带上。
