直接收回PROCESS权限即可彻底阻断普通用户查看他人进程的能力，这是唯一可靠、即时生效、不影响业务读写的手段；因PROCESS是全局权限，仅支持ON .语法，写成库或表级会报错，且必须匹配原授权host并执行FLUSH PRIVILEGES后验证。
直接收回 PROCESS 权限即可彻底阻断普通用户查看他人进程的能力，这是唯一可靠、即时生效、不影响业务读写的手段。
为什么 REVOKE PROCESS ON *.* 是必须且唯一的操作
MySQL 的 PROCESS 权限是全局权限，不支持数据库或表级限定。只要用户拥有它，执行 SHOW PROCESSLIST 或查 information_schema.PROCESSLIST 就能看到所有连接的 User、Host、Info（含明文 SQL），哪怕只是 SELECT * FROM users WHERE token = 'abc123' 这类语句也会完整暴露。
- 写成
REVOKE PROCESS ON mydb.*会报错ERROR 1221 (HY000): Incorrect usage of DB GRANT and GLOBAL PRIVILEGES - 只靠建用户时不给权限没用——MySQL 默认隐式授予
USAGE，而PROCESS可能残留 - 必须显式执行
REVOKE PROCESS ON *.* FROM 'user'@'host'，且范围要和当初GRANT完全一致（比如当初是@'%'，就不能只 revoke@'192.168.1.%'）
收回后必须立刻 FLUSH PRIVILEGES 并验证
权限变更不会自动刷新，缓存未清则行为不变。验证不能只看 SHOW GRANTS，得实际切换用户测试：
- 用目标用户登录后执行
SHOW PROCESSLIST：应只返回自己的一两行，Info字段可见但仅限当前语句（前 100 字符），其他用户行完全不可见 - 查
information_schema.PROCESSLIST会直接报错ERROR 1227 (42501): Access denied - 检查底层字段是否真为
N：SELECT User, Host, Process_priv FROM mysql.user WHERE User = 'user'，确认Process_priv列值为'N'
容易被绕过的间接路径必须同步封堵
即使 PROCESS 被收回，用户仍可能通过 performance_schema.threads 或 sys.session 窥探——这些路径在 MySQL 8.0+ 中受同一权限控制，但默认不显式限制：
- 必须额外执行：
REVOKE SELECT ON performance_schema.* FROM 'user'@'host' - 同样执行：
REVOKE SELECT ON sys.* FROM 'user'@'host' - 否则用户执行
SELECT PROCESSLIST_INFO FROM performance_schema.threads WHERE PROCESSLIST_USER = 'other'仍可能拿到部分上下文（字段值为NULL是理想状态，但未 revoke 就可能非空）
监控账号常被忽略，这才是真实风险点
真正出问题的往往不是应用账号，而是内网部署的监控脚本所用的账号。它通常被误授 PROCESS 权限以便采集指标，一旦该账号凭证泄露或服务失陷，等于把整个实例的实时运行快照交了出去——SQL、IP、连接时长、状态全量暴露。这个权限不该出现在任何应用连接字符串里，也不该用 @'%' 泛授权。最小化不是建议，是强制底线。
