<p>GRANT PROCESS ON . 是唯一合法写法，因PROCESS是全局权限，不支持库或表级限定，指定mydb.*等会报ERROR 1221；必须配合FLUSH PRIVILEGES生效，且仅用于查看全部线程，不可替代为performance_schema.SELECT。</p>
GRANT PROCESS ON *.* 是唯一合法写法
PROCESS 权限属于全局权限（Global Privilege），不能绑定到具体数据库或表。任何试图指定库名的写法都会报错：ERROR 1221 (HY000): Incorrect usage of DB GRANT and GLOBAL PRIVILEGES。
常见错误包括：
-
GRANT PROCESS ON mydb.* TO 'monitor'@'%'❌ -
GRANT PROCESS ON performance_schema.* TO 'monitor'@'%'❌ -
GRANT PROCESS ON . TO 'monitor'@'%'❌（语法不完整）
正确写法只有一种：GRANT PROCESS ON *.* TO 'monitor'@'10.0.1.%' ✅
host 部分可自由指定（如 'localhost'、'%'），但权限作用范围始终是整个 MySQL 实例，和 host 无关。
必须执行 FLUSH PRIVILEGES 才能生效
MySQL 不会自动刷新权限缓存。即使 GRANT 命令返回成功，目标用户仍可能继续只能看到自己的线程 —— 因为权限还“躺在磁盘上”，没加载进内存。
务必在 GRANT 后立刻执行：FLUSH PRIVILEGES；
验证是否生效的方法是：用该用户登录后执行 SHOW PROCESSLIST，检查结果中是否出现其他用户的 User 值（如 root、admin）。如果只有一行且 User 等于自己，说明权限未加载，或 host 匹配失败（比如授权的是 'monitor'@'10.0.1.%'，但实际连接用的是 'monitor'@'localhost'）。
为什么不能用 SELECT FROM performance_schema.processlist 替代
MySQL 8.0+ 允许对 performance_schema.processlist 视图授 SELECT 权限，但普通用户查它默认仍只能看到本用户会话 —— 想突破这个限制，必须额外授予 CONNECTION_ADMIN 或 SUPER，而这两种权限远超监控所需，且违背最小权限原则。
GRANT SELECT ON performance_schema.processlist TO 'monitor'@'%' → 结果仍只有当前用户的一行GRANT CONNECTION_ADMIN ON *.* TO 'monitor'@'%' → 可查全部，但也能 KILL 任意线程、修改连接属性，风险不可控
PROCESS 是单向只读权限，而 CONNECTION_ADMIN 是双向控制权。监控场景下，没有理由绕开 PROCESS 去碰更危险的替代方案。
监控账号应搭配 SELECT 和 REPLICATION CLIENT 使用
单独给 PROCESS 不足以支撑完整监控。第三方采集器（如 mysqld_exporter）需要三类基础能力：
-
SELECT：查information_schema和performance_schema中的统计视图（如table_io_waits_summary_by_table） -
PROCESS：执行SHOW PROCESSLIST获取全部连接与运行中 SQL -
REPLICATION CLIENT：执行SHOW SLAVE STATUS、SHOW MASTER STATUS获取主从状态
别加 SHOW DATABASES —— 它会让监控账号列出所有库名，构成信息泄露；也别用 ALL PRIVILEGES ON *.*，那是把实例钥匙直接交出去。
真正容易被忽略的是 Info 字段的内容风险：SHOW PROCESSLIST 返回的 SQL 文本是明文，可能含密码、密钥、敏感条件。一旦账号泄漏，攻击者可直接拿到这些上下文。所以 PROCESS 权限本身就有暴露面，不该随意授予非必要人员。
