all privileges on . 不等于真有全部权限，必须同时满足on .和with grant option才生效；需查mysql.user表中super_priv、grant_priv等字段是否为'y'，并检查mysql.db表中db='*'的伪全局账号。
怎么看“所有权限”是不是真给了 *.*
phpmyadmin 界面里点开某个用户 → “编辑权限”，看到“全局权限”下全勾选了，不代表它真有 all privileges on *.*。界面常把 select、insert 等单个权限打钩就显示为“全部”，但漏掉关键判断条件：with grant option 是否启用、是否通过角色继承获得权限、甚至 db='*' 这种伪全局配置（藏在 mysql.db 表里）完全不显示。
实操建议：
- 别信界面上的“全选”状态，直接切到
SQL标签页运行：SHOW GRANTS FOR 'user'@'host'; - 重点看输出里有没有
ON *.*和WITH GRANT OPTION—— 两者同时出现，就是高危信号 - 如果看到
USING 'role_name'，说明权限来自角色，得再查：SELECT * FROM mysql.role_edges WHERE TO_USER = 'role_name';
为什么搜 Super_priv = 'Y' 比看界面更准
界面“用户账户”列表默认只显示用户名和主机，不展示 Super_priv、Grant_priv、Create_user_priv 这类高危字段。而这些权限一旦开启，用户就能执行 KILL、SHUTDOWN、创建其他用户等破坏性操作，且不受数据库级权限限制。
实操建议：
- 进 phpMyAdmin 的
mysql库 →user表 → 点“搜索”页签 - 字段选
Super_priv、Grant_priv、Create_user_priv，值全设为Y - 更省事的是直接跑 SQL：
SELECT User, Host FROM mysql.user WHERE Super_priv = 'Y' OR Grant_priv = 'Y' OR Create_user_priv = 'Y';
怎么发现“看着普通、实则通杀”的伪全局账号
有些账号没被授 *.*，却对所有库都有操作权——因为它的记录在 mysql.db 表里：Host 是 % 且 Db 是 *（注意：这是通配符，不是字面星号）。这种配置等效于全局权限，但 phpMyAdmin 用户列表和“编辑权限”页完全不体现。
实操建议：
- 在
SQL标签页运行：SELECT User, Host, Db FROM mysql.db WHERE Host = '%' AND Db = '*'; - 结果里的每个账号，都应被当作
*.*权限持有者来审查 - 这类账号无法在界面里直接编辑权限，必须用
REVOKE或DROP USER处理
删不掉的僵尸账号，往往权限已失控
发现一个长期不用、权限又很高的账号，想删却提示失败？常见原因是用了 DELETE FROM mysql.user 手动删行。MySQL 不会自动刷新权限缓存，残留状态会导致后续 FLUSH PRIVILEGES 都不生效，甚至让该账号仍能登录但权限错乱。
实操建议：
- 绝对不要手动删
mysql.user行，一律用：DROP USER 'username'@'host'; - 如果报错
ERROR 1396 (HY000)，先在 SQL 页开头加：SET sql_mode = '';，再执行DROP USER - 删完立刻用另一个高权限账号验证：
SELECT User, Host FROM mysql.user WHERE User = 'username';，确保无残留
真正难处理的不是权限本身，而是权限来源的不可见性：角色继承、mysql.db 通配、GRANT OPTION 的隐式传播——这些都不会在 phpMyAdmin 界面里亮红灯，但每一条都可能成为突破口。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
