Super_priv和Grant_priv是关键指标，因前者可kill线程、修改全局变量、写binlog，后者能任意授/回收权限，任一为Y即具备横向提权能力；需结合mysql.role_edges和mysql.proxies_priv交叉验证，避免仅依赖SHOW GRANTS遗漏角色继承与代理权限。
查 mysql.user 表时为什么 Super_priv 和 Grant_priv 是关键指标？
这两个字段直接决定账号能否绕过权限系统做破坏性操作。Super_priv 允许 kill 线程、修改全局变量、写入 binlog；Grant_priv 则能任意授予/回收他人权限——两者任一为 Y，该账号就具备横向提权能力。
常见误判是只看 SELECT/INSERT 权限，但高危账号往往权限“看起来很干净”，实则靠这两项暗度陈仓。
注意：MySQL 8.0+ 中部分权限已迁移到 mysql.role_edges 和 mysql.proxies_priv，但 Super_priv 和 Grant_priv 仍在 mysql.user 中保留且生效。
执行以下语句快速定位：
SELECT host, user, Super_priv, Grant_priv, authentication_string FROM mysql.user WHERE Super_priv = 'Y' OR Grant_priv = 'Y';
为什么不能只依赖 SHOW GRANTS？
SHOW GRANTS FOR 'user'@'host' 只显示显式授予的权限，不反映角色继承、代理权限（PROXY）、或通过 SET DEFAULT ROLE 激活的隐式权限。
更隐蔽的是：MySQL 5.7+ 支持 CREATE USER 时不赋任何权限，但若该用户被加入拥有 GRANT OPTION 的角色，它就能间接获得高危能力。
所以必须交叉验证：mysql.user + mysql.role_edges + mysql.default_roles。
检查角色继承链：
SELECT r.from_host, r.from_user, r.to_host, r.to_user, u.Super_priv, u.Grant_priv FROM mysql.role_edges r JOIN mysql.user u ON r.to_host = u.host AND r.to_user = u.user WHERE u.Super_priv = 'Y' OR u.Grant_priv = 'Y';
mysql.proxies_priv 表里的 Grant_priv 字段意味着什么？
这个表控制代理权限（proxy privileges），即“A 用户可冒充 B 用户执行操作”。如果某行的 Grant_priv 为 Y，说明代理者不仅能以被代理者身份登录，还能代其执行 GRANT ——等效于双重高危权限。
典型风险场景：运维账号 'dba'@'%' 被设为 'app'@'10.0.1.%' 的 proxy，并开了 Grant_priv，那么应用服务器上的任意数据库连接都可能升级为权限提升入口。
该表默认只在启用 check_proxy_users 且配置了代理关系时才有数据，但一旦存在，就必须纳入扫描范围。
检查代理高危配置：
SELECT Host, User, Proxied_host, Proxied_user, Grant_priv FROM mysql.proxies_priv WHERE Grant_priv = 'Y';
为什么 authentication_string 为空或为 * 的账号要重点盯防？
空密码（authentication_string = ''）或弱哈希（如 MySQL 5.6 的 * 开头旧格式）本身不是权限问题，但会极大降低攻击门槛。一旦网络层暴露（比如意外绑定到公网、跳板机未加固），这类账号就是最短路径的突破口。
尤其要注意：MySQL 8.0 默认使用 caching_sha2_password，若 authentication_string 显示为 *，大概率是旧版本迁移残留，且密码未重置——此时即使权限不高，也极可能成为跳板。
不要仅凭 plugin 字段判断安全性，必须结合 authentication_string 内容和实际密码强度交叉验证。
快速筛出可疑认证状态：
SELECT host, user, plugin, authentication_string FROM mysql.user WHERE authentication_string = '' OR authentication_string LIKE '*%';权限分析真正难的不是查表，而是理解哪些组合会在特定部署拓扑下形成隐式提权通路——比如一个只有
SELECT 权限的账号，若同时在 proxies_priv 中被授权代理高权限账号，它就不再是“只读”账号。 
