直接 revoke show processlist 权限不总管用，因 mysql 5.7+ 将其与 super 绑定，8.0+ 还新增 connection_admin 隐式授权，且 performance_schema.threads 和 information_schema.processlist 的 select 权限也可间接泄露进程信息。
为什么直接 revoke show processlist 权限不总管用
mysql 5.7+ 默认把 show processlist 权限和 super 绑定，哪怕你显式 revoke show processlist on *.* from 'user'@'%'，只要用户还有 super，照样能执行。更隐蔽的是，8.0+ 引入了 connection_admin，它也隐式包含该能力——很多人删了 super 却忘了查这个。
-
SUPER和CONNECTION_ADMIN是“高权限开关”，优先级高于单独的SHOW PROCESSLIST - 普通账号如果被授予
SELECT权限到performance_schema.threads或information_schema.PROCESSLIST，也能间接看到进程列表 - root 用户默认绕过权限检查（尤其在旧版本），不是靠授权控制，而是靠认证逻辑
彻底禁用的实际操作步骤
分三步走：先清高权限、再关元数据表访问、最后验证是否真失效。顺序不能错，否则前两步白做。
- 查当前用户权限：
SHOW GRANTS FOR 'user'@'%';，重点盯SUPER和CONNECTION_ADMIN - 回收高权限：
REVOKE SUPER, CONNECTION_ADMIN ON *.* FROM 'user'@'%'; - 堵住元数据入口：
REVOKE SELECT ON performance_schema.threads FROM 'user'@'%';，同时REVOKE SELECT ON information_schema.PROCESSLIST FROM 'user'@'%'; - 刷新权限：
FLUSH PRIVILEGES;
测试是否真的禁用了
别只信 SHOW GRANTS 输出，得亲手试。用目标账号登录后执行以下命令，任一成功都说明没禁干净：
-
SHOW PROCESSLIST;—— 应报错ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER or CONNECTION_ADMIN privilege(s) for this operation -
SELECT * FROM performance_schema.threads LIMIT 1;—— 应报ERROR 1142 (42000): SELECT command denied to user ... for table 'threads' -
SELECT * FROM information_schema.PROCESSLIST LIMIT 1;—— 同样应报权限拒绝
容易被忽略的兼容性细节
MySQL 5.6 和 8.0 的行为差异很大，同一套操作在不同版本可能效果相反：
- 5.6 不支持
CONNECTION_ADMIN，但SUPER是唯一开关；8.0 必须同时处理两个权限 - 开启
performance_schema是前提，如果它被关了（performance_schema=OFF），threads表不可见，但SHOW PROCESSLIST仍可能生效 - 某些云数据库（如阿里云 RDS）会强制开启
performance_schema且不允许改配置，这时必须确保REVOKE SELECT落到实处
真正卡住的点往往不在权限语句本身，而在版本判断不准、元数据表路径没封全、或者误以为 root 的限制逻辑和其他用户一样。
