最快方式是查mysql.user表Super_priv='Y'或Grant_priv='Y'，因二者代表最高风险权限；MySQL 8.0+需同步检查Account_locked及角色继承链，且必须用DROP USER而非DELETE清理，审计须从mysql.user开始逐层向下验证。
查哪些用户有 Super_priv 或 Grant_priv
直接看 mysql.user 表里这两个字段是最快的方式，因为它们代表最高风险权限：拥有 super_priv='y' 的用户能 kill 连接、修改全局变量、绕过所有权限检查；grant_priv='y' 则允许其给其他人授予权限，极易失控。
执行这条 SQL：
SELECT User, Host, Select_priv, Insert_priv, Update_priv, Delete_priv, Grant_priv, Super_priv FROM mysql.user WHERE Super_priv = 'Y' OR Grant_priv = 'Y';
-
Host值必须一起看——'admin'@'localhost'和'admin'@'%'是两个独立账户，不能互相替代，但都开Super_priv就属于冗余 - 如果结果里出现非运维人员（比如
'app_user'@'10.0.2.%'），基本可以判定权限过度授予 - MySQL 8.0+ 中还要留意
Account_locked字段，避免误删被锁但仍有高权的账号
比对同名用户在不同 Host 上的权限重复
批量建号时复制粘贴容易导致同一用户名在多个 Host 上重复获得 ALL PRIVILEGES，比如 'deploy'@'192.168.1.%' 和 'deploy'@'192.168.1.100' 都开了 Grant_priv，实际只需保留更精确的那个。
用这个查询快速定位：
SELECT User, COUNT(DISTINCT Host) AS host_count FROM mysql.user WHERE Super_priv = 'Y' OR Grant_priv = 'Y' GROUP BY User HAVING host_count > 1;
- 结果里
host_count > 1的用户，要逐个点开“编辑权限”，确认每个Host是否真有必要保留高权 - 删之前先运行
SHOW GRANTS FOR 'user'@'host';，避免误删后才发现某个Host承担着关键自动化任务 - 禁止直接
DELETE FROM mysql.user——必须用DROP USER 'user'@'host';，否则残留记录可能干扰权限计算
验证高权用户是否被数据库级权限覆盖
一个用户已有 Super_priv='Y'，再给他 myapp.* ALL PRIVILEGES 完全多余；但反过来，如果只删了库级权限，而 Super_priv 还开着，那清理就毫无意义。
立即学习“PHP免费学习笔记（深入）”；
重点检查权限继承链顺序：
- 先看
mysql.user：只要Super_priv='Y'，其他所有层级权限都失效 - 再看
mysql.db：若该用户在此表中有对应Db记录且Select_priv='Y'，但mysql.user里Super_priv='N'，才真正生效 -
mysql.tables_priv同理，只有上层没覆盖时才起作用
所以审计时永远从 mysql.user 开始，而不是倒过来查表级权限——否则你会花时间清理一堆根本没生效的冗余授权。
用 SHOW GRANTS 确认真实生效权限
SHOW GRANTS FOR 'user'@'host'; 返回的是 MySQL 实际合成后的权限语句，比手动 JOIN 多张系统表更可靠，尤其在 MySQL 8.0+ 权限字段变动频繁的情况下。
注意两个现实约束：
- 执行该命令需要当前登录账号对
mysql库有SELECT权限，或具备SYSTEM_USER特权（MySQL 8.0.17+） - 结果中带
WITH GRANT OPTION的行，说明该用户能转授权限，但你无法从输出里知道他已转授给了谁——这部分信息不落盘，只能靠日志或人工记录追溯 - 如果某用户权限看起来“应该生效”但实际连不上，优先跑
SHOW GRANTS，再对比连接时用的User和Host是否完全匹配（比如客户端解析出的 IP 是192.168.1.100，但权限只给了'user'@'192.168.1.%'，中间 DNS 解析差异会导致失败）
真正的难点不在查，而在判断“这个高权到底是不是业务必需”。比如 CI/CD 账户需要 CREATE 和 DROP，但不该有 FILE；监控账户需要 PROCESS，但绝不能碰 SUPER。每一条高权背后，都得有明确的、可验证的业务依据。
