不能靠单个字段排序查看权限最大的前五个用户，因为mysql.user表的权限字段是'y'/'n'字符串，无数值大小关系，无法反映真实权限组合或库级权限，且字段值可能滞后于实际权限状态。
不能靠单个字段排序来“快速查看权限最大的前五个用户”——mysql.user 表里的权限字段是离散布尔值，没有数值大小关系，强行按 Select_priv 或 Super_priv 排序毫无业务意义。
为什么不能用 ORDER BY Super_priv DESC LIMIT 5
MySQL 5.7 的 mysql.user 表中所有权限字段（如 Select_priv、Insert_priv、Super_priv）都是 'Y' 或 'N' 字符串，不是数字。按字符串排序时，'Y' 和 'N' 的 ASCII 值差异无法反映“权限大小”，更无法体现组合效果（比如有 Super_priv='Y' 但没 Grant_priv 的用户，实际权限远不如一个 Grant_priv='Y' + 所有 DML 权限全开的账号）。
- 执行
SELECT User, Host, Super_priv FROM mysql.user ORDER BY Super_priv DESC LIMIT 5只会把所有'Y'排前面、'N'排后面，结果固定且无区分度 - 多个
'Y'用户之间无法进一步排序：谁更“大”，表里没定义 - 完全忽略
mysql.db等表授予的库级权限，例如'monitor'@'%'在mysql.user全是'N'，却在mysql.db对performance_schema有Create_priv='Y'，配合 INSERT 就能写入新高权限账号
真正有效的“权限最大”筛选逻辑
运维中公认的高权限标志是：能改全局状态（SUPER）、能授予权限（GRANT OPTION）、或拥有全部 DML+DDL 权限（SELECT+INSERT+UPDATE+DELETE+CREATE+DROP 等全为 'Y'）。需组合判断，而非排序。
- 先筛出显式高危账号：
SELECT User, Host FROM mysql.user WHERE Super_priv = 'Y' OR Grant_priv = 'Y' - 再补查“全能型”账号：
SELECT User, Host FROM mysql.user WHERE Select_priv = 'Y' AND Insert_priv = 'Y' AND Update_priv = 'Y' AND Delete_priv = 'Y' AND Create_priv = 'Y' AND Drop_priv = 'Y' AND Alter_priv = 'Y' AND Index_priv = 'Y' - 这两组结果取并集（
UNION），就是最可能具备实质管理能力的账号集合 - 若结果超过 5 个，优先保留含
Super_priv = 'Y'的行——因为SUPER可绕过大部分权限检查（如 kill 线程、修改read_only）
必须同步检查 mysql.db 表才能避免漏检
仅查 mysql.user 是严重误判。很多生产环境的 DBA 账号被刻意设为 Super_priv = 'N'，但通过 mysql.db 获得对 mysql 库的完整操作权，等价于可控 user 表本身。
- 执行：
SELECT DISTINCT User, Host FROM mysql.db WHERE Db = 'mysql' AND (Select_priv = 'Y' OR Insert_priv = 'Y' OR Update_priv = 'Y' OR Delete_priv = 'Y' OR Create_priv = 'Y' OR Drop_priv = 'Y') - 这个结果里的账号，哪怕
mysql.user全是'N'，也应立即列入高权限名单 - 注意：该查询依赖
Db字段精确匹配'mysql'（大小写敏感），不能写成LIKE '%mysql%'
最终建议：用 SHOW GRANTS 逐个验证，别信字段快照
SHOW GRANTS FOR 'user'@'host' 是唯一反映真实权限的状态。字段值不会自动更新——刚执行 GRANT SUPER ON *.* TO 'a'@'%' 后不 FLUSH PRIVILEGES，Super_priv 仍为 'N'，但权限已生效；反之亦然。
- 对上一步筛选出的候选用户，逐个运行
SHOW GRANTS FOR 'u'@'h'，看输出是否含SUPER、GRANT OPTION或ALL PRIVILEGES ON *.* - 特别留意输出中是否有
WITH GRANT OPTION——这是权限扩散的关键风险点 - 如果账号数不多（比如 ≤20），手动验证比写复杂 SQL 更可靠；自动化检测必须调用
SHOW GRANTS并解析文本，而非查表
真正危险的从来不是字段显示 'Y' 的账号，而是那些字段全 'N' 却在 mysql.db 拥有 mysql 库写权限、或通过应用配置悄悄获得 GRANT OPTION 的用户——这些靠排序和单表查询永远看不到。
