查 mysql.user 表的 super_priv 字段最直接：值为'y'表示拥有super权限，'n'表示没有；8.0+中该字段为boolean类型（1/0），但可兼容用'y'/'n'查询；需结合system_variables_admin、role_admin等新权限及show grants验证实际生效权限。
查 mysql.user 表的 Super_priv 字段最直接
MySQL 的超级管理员权限（即 SUPER）是否赋予某个账户，核心依据就是 mysql.user 系统表里的 Super_priv 字段。该字段值为 'Y' 表示拥有，'N' 表示没有。注意：5.7 及以前版本用的是 Y/N 字符串；8.0+ 改为 BOOLEAN 类型（实际存储为 1/0），但查询时仍可统一用字符串比较兼容旧写法。
执行这条语句就能列出所有带 SUPER 权限的账号：
SELECT Host, User, Super_priv FROM mysql.user WHERE Super_priv = 'Y';
别漏掉 Host 列——同一个 User 在不同主机来源（比如 'root'@'localhost' 和 'root'@'%'）是独立账户，权限可能完全不同。
别只看 SUPER，顺手检查 SYSTEM_VARIABLES_ADMIN 和 ROLE_ADMIN
MySQL 8.0+ 引入了更细粒度的权限模型，SUPER 被逐步拆解。即使 Super_priv = 'N'，账户也可能通过新权限组合实现等效能力：
-
SYSTEM_VARIABLES_ADMIN：能动态修改全局系统变量（如max_connections、sql_mode），相当于过去SUPER的一部分关键能力 -
ROLE_ADMIN：可创建、删除、授予/撤销角色，间接控制权限分发链路 -
SET_USER_ID或REPLICATION_SLAVE_ADMIN在特定场景下也可能构成提权路径
建议补查这句（适用于 8.0+）：
SELECT Host, User, Super_priv, System_variables_admin, Role_admin FROM mysql.user WHERE Super_priv = 'Y' OR System_variables_admin = 'Y' OR Role_admin = 'Y';
用 SHOW GRANTS 验证具体生效权限，避免视图缓存误导
mysql.user 表反映的是“静态授权状态”，但权限实际生效还受当前连接上下文影响。比如账户被 REVOKE 后未执行 FLUSH PRIVILEGES，或使用了角色（SET ROLE）临时激活权限，仅查表会漏判。
对可疑账户，务必用 SHOW GRANTS 实时验证：
SHOW GRANTS FOR 'admin_user'@'192.168.%';
如果返回结果里明确出现 GRANT SUPER ON *.* TO ... 或 GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO ...，才确认该连接具备对应能力。注意：必须用完整 User@Host 格式，否则 MySQL 默认查 @''（空 host）匹配，容易查错。
排查时容易忽略的三个硬坑
实际排查中，这几个点最容易导致误判或漏查：
- MySQL 8.0 默认禁用
root账户的SUPER，改用SYSTEM_VARIABLES_ADMIN等组合权限，直接查Super_priv = 'Y'会漏掉 root -
mysql.user表不记录角色继承的权限，只存显式授予的权限。若用户通过角色获得SUPER，需先查mysql.role_edges追溯角色链 - 某些云数据库（如阿里云 RDS、腾讯云 CDB）屏蔽了直接访问
mysql系统库的权限，此时只能依赖SHOW GRANTS或控制台权限管理页
真正要确认一个账户能不能执行 SET GLOBAL 或 KILL 任意线程，最终得靠 SHOW GRANTS + 实际尝试，表字段只是第一道筛子。
