应检查super_priv、file_priv、repl_slave_priv、grant_priv字段为'y'的账号，并过滤user=''或host='%'等高危配置，因真实权限是角色继承、动态权限与proxy机制叠加的结果，仅靠show grants无法全面反映。
查 mysql.user 表里高危字段值为 'Y' 的账号
直接查 mysql.user 是最快速暴露风险的方式，但不能只看有没有 GRANT OPTION，得盯住几个能绕过常规限制的权限字段。这些字段值为 'Y' 时，往往意味着账户已超出业务所需能力：
-
Super_priv = 'Y'：可 kill 任意连接、修改全局变量、绕过sql_mode限制，连慢查询日志都能关掉 -
File_priv = 'Y'：配合SELECT ... INTO OUTFILE或LOAD DATA INFILE，能读写服务器任意文件（包括/etc/passwd） -
Repl_slave_priv = 'Y'：常被忽略——它允许伪造从库身份，再结合LOAD DATA LOCAL INFILE可触发服务端任意文件读取 -
Grant_priv = 'Y'：该用户能再授予权限，一旦泄漏，等于整个权限体系失控
执行这句就能定位核心风险点：SELECT User, Host, Super_priv, File_priv, Repl_slave_priv, Grant_priv FROM mysql.user WHERE Super_priv = 'Y' OR File_priv = 'Y' OR Repl_slave_priv = 'Y' OR Grant_priv = 'Y';
过滤 Host 为 '%' 或空字符串的账户
权限再小，只要 Host 是 '%' 或空，就等于把门开在公网。攻击者不需要猜密码，只要爆破成功或利用弱口令，就能直连执行任意语句。
这两类账户必须优先处理：
-
User = ''（匿名用户）：MySQL 默认可能创建，允许无用户名登录，DROP USER ''@'localhost';必须执行 -
Host = '%'：尤其是'root'@'%'，等同于放弃主机层访问控制，应立即删或改为主机白名单，如'root'@'10.10.20.5' -
Host包含通配符（如'%.example.com'）：需确认 DNS 解析是否可控，否则可能被域名劫持绕过
快速筛查命令：SELECT User, Host FROM mysql.user WHERE User = '' OR Host = '%';
别信 SHOW GRANTS 输出的“干净”结果
SHOW GRANTS FOR 'u'@'h' 只显示显式授予的权限，对角色继承、动态权限、PROXY 权限完全不体现。一个看起来只有 SELECT 的账号，可能通过角色间接拿到 ALL PRIVILEGES ON *.*。
要真正看清权限全貌，得组合查三处：
- 角色链：
SELECT FROM_HOST, TO_HOST FROM mysql.role_edges WHERE TO_HOST = 'u'@'h';，再对每个FROM_HOST查其权限 - 动态权限（MySQL 8.0+）：
SELECT * FROM information_schema.role_table_grants WHERE GRANTEE = '''u''@''h''';，或直接查performance_schema.role_edges - PROXY 权限：
SELECT * FROM mysql.proxies_priv WHERE Host = 'h' AND User = 'u';，这类权限不会出现在SHOW GRANTS里，但允许代理登录并继承被代理用户的全部权限
警惕 mysql.* 库的过度授权
给业务账号授予 mysql.* 权限，等于把用户密码哈希（mysql.user.authentication_string）、权限规则（mysql.db）、甚至函数定义（mysql.func）全暴露出去。哪怕只是 SELECT，也足以支撑脱库后离线爆破。
常见危险授权模式：
-
GRANT SELECT ON mysql.* TO 'app_user'@'%';—— 导致密码哈希泄露 -
GRANT INSERT ON mysql.tables_priv TO 'dev_user'@'192.168.1.%';—— 等于开放权限写入入口 -
GRANT ALL ON mysql.* TO 'backup_user'@'10.0.0.%';—— 备份账号不该有 DDL 能力
检查命令：SELECT Grantee, Table_schema, Table_name, Privilege_type FROM information_schema.role_table_grants WHERE Table_schema = 'mysql' AND Privilege_type != 'USAGE';
真实权限是叠加结果，不是单张表或一条命令能说清的。最容易被跳过的，是角色嵌套三层以上、PROXY 用户未显式声明、以及 DEFINER 函数执行时的隐式提权——这些都不会报错，但会在某次 SQL 执行中突然越界。
