最准方法是直接查mysql.user表并结合mysql.db、mysql.role_edges等系统表，因phpMyAdmin界面会遗漏GRANT OPTION、角色继承权限及Db='*'等伪全局权限。
怎么看哪些用户有 ALL PRIVILEGES ON *.*
想知道谁手握数据库的“生杀大权”？最直接、最可靠的方法，就是去查 mysql.user 这张核心系统表。在phpMyAdmin里，找到这个库和表，加个简单的筛选条件就能一目了然。这里有个关键提醒：千万别完全相信图形界面“权限”标签页里的汇总信息——它通常只展示那些被显式授予的权限，而像 GRANT OPTION（授权权限）或者通过角色继承来的权限，很容易就被漏掉了。
具体可以这么操作：
立即学习“PHP免费学习笔记（深入）”；
- 在phpMyAdmin中，进入
mysql库，打开user表，切换到“搜索”页签。将关键权限字段如Super_priv、Grant_priv、Reload_priv的值都设为Y进行筛选。 - 更稳妥的方式是直接执行SQL查询：
SELECT User, Host FROM mysql.user WHERE Super_priv = 'Y' OR Grant_priv = 'Y' OR Create_user_priv = 'Y';
- 需要警惕的是：虽然MySQL 8.0+默认禁用了
root@localhost的远程访问，但如果存在root@'%'这样的用户，那就是一个明确的高风险点。
为什么 SHOW GRANTS FOR 'user'@'host' 比界面更可靠
phpMyAdmin的“用户账户”页面确实方便，它会把权限分门别类地展示出来。但问题恰恰出在这里：像 SHUTDOWN、PROCESS 这类全局权限，在图形界面里经常被折叠，或者归类得模糊不清，甚至干脆不显示。相比之下，SHOW GRANTS 命令返回的是MySQL服务器内部实际执行的授权语句，原汁原味，没有任何歧义。
常见的“踩坑”场景包括：
- 界面上看到“所有数据库权限”打了勾，却没注意到是否包含了关键的
WITH GRANT OPTION（允许该用户给他人授权）。 - 用户被赋予了
PROXY权限（可以冒充其他用户），但界面可能只字不提。 - 在MySQL 8.0+中使用了角色（Roles），界面可能只显示角色名称，而不会展开列出这个角色具体拥有哪些权限。
因此，建议养成这个习惯：
立即学习“PHP免费学习笔记（深入）”；
- 在phpMyAdmin的“SQL”页签里直接运行命令：
SHOW GRANTS FOR 'admin'@'192.168.%';
- 仔细审视输出结果，重点盯住有没有
ON *.*和WITH GRANT OPTION这些字眼。 - 如果看到
USING 'role_name'这样的语句，说明权限来自角色，必须进一步查询：SELECT * FROM mysql.role_edges WHERE TO_HOST = 'role_name';
mysql.db 和 mysql.tables_priv 里藏着“伪全局权限”
有些用户的权限配置堪称“隐形杀手”。他们明明没有被授予 *.* 这样的全局权限，却实际上能操作所有数据库。秘密就藏在 mysql.db 系统表里：当某个用户的 Host 字段是 %，并且 Db 字段也是通配符 * 时，这就等效于拥有了全局权限。然而，这种配置在phpMyAdmin的用户列表里是完全不体现的。
这种情况通常出现在：
- 从旧版本迁移遗留的权限配置，管理员误以为只给了数据库级权限，实际上却是通配符。
- 脚本自动创建用户时，
Db字段拼写错误，写成了'*'而不是类似'test\_%'这样的模式。
排查这类隐藏风险，可以这么做：
立即学习“PHP免费学习笔记（深入）”；
- 查询
mysql.db表：SELECT User, Host, Db FROM mysql.db WHERE Db = '*' AND Host != 'localhost';
- 检查
mysql.tables_priv表中，是否存在Table_name = '%'且Db = '*'的记录（虽然少见，但确实存在）。 - 值得注意的是，这类通过系统表直接配置的“伪全局权限”，无法用
SHOW GRANTS命令直接还原查看，必须查询系统表本身。
MySQL 8.0+ 的角色权限容易被 phpMyAdmin 忽略
角色（Roles）是MySQL 8.0引入的强大功能，但早期版本的phpMyAdmin（如4.9及更早）对它的支持相当薄弱。点开用户详情，很可能看不到其激活的角色，更不会递归展示角色所携带的所有权限。这就导致一个现象：一个用户自身的权限看起来平平无奇，但一旦执行了 SET DEFAULT ROLE all_power TO 'dev'@'%';，他就瞬间拥有了全部权限。
这带来的主要影响是：
- 权限检查性能上，角色权限比直接授权略慢，但审计时的核心问题是“看不见”，导致权限评估失真。
- phpMyAdmin 5.0+ 开始支持角色列表，但默认可能未启用；需要确认配置中的
$cfg['Servers'][$i]['AllowRoot']和auth_type是否允许读取mysql.role_edges系统表。
因此，在MySQL 8.0+环境中，审计时必须额外关注角色：
立即学习“PHP免费学习笔记（深入）”；
- 强制检查所有角色分配关系：
SELECT FROM_USER, FROM_HOST, TO_USER, TO_HOST FROM mysql.role_edges;
- 查询特定用户的默认角色：
SELECT Default_role FROM mysql.default_roles WHERE USER = 'api' AND HOST = '%';
- 核心建议：在升级到MySQL 8.0之后，切勿再单纯依赖phpMyAdmin的“权限”页签做最终的安全判断。
总结来说，真正的风险往往不在明处的 root，而在于那些权限分散在多张系统表、又混合了角色和通配符的账号——它们在phpMyAdmin的图形界面里最不起眼，却恰恰是安全审计中最容易被遗漏的盲点。
