MySQL中无直接代表“ALL PRIVILEGES”的字段，而是通过Select_priv、Insert_priv、Update_priv、Delete_priv、Create_priv、Drop_priv等29个以_priv结尾的权限字段全为'Y'来体现全局全部权限。
查 mysql.user 表里哪些字段代表 ALL PRIVILEGES
MySQL 并不直接在 user 表中存一个叫 “ALL PRIVILEGES” 的标记。所谓 GRANT ALL PRIVILEGES，本质是把所有细粒度权限字段（如 Select_priv、Insert_priv、Create_priv 等）全设为 'Y'。所以判断依据是：这些关键权限列是否全部为 'Y'。
需要重点关注的字段包括：Select_priv、Insert_priv、Update_priv、Delete_priv、Create_priv、Drop_priv、Reload_priv、Shutdown_priv、Process_priv、File_priv、Grant_priv、References_priv、Index_priv、Alter_priv、Show_db_priv、Super_priv、Create_tmp_table_priv、Lock_tables_priv、Execute_priv、Repl_slave_priv、Repl_client_priv、Create_view_priv、Show_view_priv、Create_routine_priv、Alter_routine_priv、Create_user_priv、Event_priv、Trigger_priv、Create_tablespace_priv —— 共 29 个（MySQL 8.0+ 完整列表）。
但实际中，真正构成“等效 ALL”的核心是前 16–18 个管理型+数据操作型字段；Super_priv 和 Create_user_priv 等属于高危特权，是否包含在内取决于你对 “ALL” 的定义边界。
用 SQL 精确匹配全部权限为 'Y' 的用户
直接查 mysql.user 表所有字段值为 'Y' 的行，但注意两点：一是必须用 AND 连接全部目标字段，二是 MySQL 8.0+ 默认启用 caching_sha2_password 认证插件，user 表结构略有变化，部分旧字段（如 password）已移除，但权限字段名保持兼容。
推荐执行以下语句（适配 MySQL 5.7 / 8.0+）：
SELECT User, Host, authentication_string 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 Reload_priv = 'Y' AND Shutdown_priv = 'Y' AND Process_priv = 'Y' AND File_priv = 'Y' AND Grant_priv = 'Y' AND References_priv = 'Y' AND Index_priv = 'Y' AND Alter_priv = 'Y' AND Show_db_priv = 'Y' AND Super_priv = 'Y' AND Create_tmp_table_priv = 'Y' AND Lock_tables_priv = 'Y' AND Execute_priv = 'Y' AND Repl_slave_priv = 'Y' AND Repl_client_priv = 'Y';
如果只想查数据库级（而非全局）的 ALL 权限用户，这个方法不适用——因为 mysql.user 只存全局权限；库/表级权限存在 mysql.db、mysql.tables_priv 等表中，需联合查询。
用 SHOW GRANTS 批量验证更可靠
SHOW GRANTS FOR 'user'@'host' 是唯一能反映“当前生效权限集合”的方式，它会合并全局 + 数据库 + 表 + 列级权限，并以可读语句形式输出。但无法直接 SQL 查询所有用户，得配合脚本或循环。
手动检查几个高风险账号时，可用：
SELECT CONCAT('SHOW GRANTS FOR ''', User, '''@''', Host, ''';') AS cmd
FROM mysql.user
WHERE Super_priv = 'Y' OR Create_user_priv = 'Y' OR Grant_priv = 'Y';然后复制结果中的命令逐条执行。这样比硬查 29 个字段更贴近真实授权状态，尤其当用户同时有 GRANT OPTION 或被 REVOKE 过部分权限时，字段值可能滞后于实际效果。
常见误判点：
-
GRANT ALL ON *.*用户在mysql.user中对应字段全为'Y'，但GRANT ALL ON mydb.*不会影响mysql.user，只写入mysql.db - MySQL 8.0+ 引入角色（
ROLE），权限可能来自角色继承，mysql.user字段仍为'N'，但SHOW GRANTS会显示角色授予的权限 -
FLUSH PRIVILEGES后权限才生效，未刷新时mysql.user表已更新，但内存缓存未同步，SHOW GRANTS可能显示旧状态
为什么不能只看 Super_priv = 'Y' 就认为是 ALL
Super_priv 是超级用户权限，允许执行 KILL、SET GLOBAL、修改全局变量等操作，但它不自动赋予 SELECT、INSERT 等数据操作权限。一个只有 Super_priv = 'Y' 但其他权限全为 'N' 的用户，连 SELECT * FROM mysql.user 都会被拒绝。
反过来说，GRANT ALL PRIVILEGES ON *.* 必然设置 Super_priv = 'Y'（MySQL 5.7+ 行为），但反过来不成立。所以单靠 Super_priv 判断会漏掉非超级但权限全开的账号（极少见），也会误报纯运维型超级账号。
真正要定位“能干任何事”的用户，必须确认其拥有完整的数据操作 + 结构变更 + 管理类权限组合，且作用域为 *.*。最稳妥的方式仍是：先用字段查询初筛，再用 SHOW GRANTS 对结果逐个确认，特别留意 WITH GRANT OPTION 是否存在——这才是权限扩散的关键开关。
