SHOW GRANTS不显示新权限，主因是phpMyAdmin默认仅更新当前选中数据库的权限（写入mysql.db表），而非全局权限；若未先在左侧导航栏选定目标库或切换至“全局权限”页，授权将无效，且Host不匹配、角色权限未显式查询、或误删权限后未用GRANT恢复也会导致该现象。
执行完权限修改后，为什么 SHOW GRANTS 不显示新权限？
常见现象是：在 phpMyAdmin 界面点“执行”后跳转回用户列表，再进“编辑权限”页，发现刚勾选的 SELECT 或 INSERT 又变回未勾选状态；或者直接运行 SHOW GRANTS FOR 'user'@'host';，输出里完全没出现新授的权限。
这不是界面刷新问题，而是权限根本没写入系统表——phpMyAdmin 5.2 的“编辑权限”页默认只更新当前数据库（即你左侧选中的那个库）的权限，而不是用户全局权限。如果你没在左侧先选中目标数据库，它会悄悄把权限写到 mysql.db 表里，但该表只对 GRANT ... ON database.* 生效，不控制登录或跨库操作。
- 务必在左侧导航栏先点击你要授权的那个数据库（比如
myapp），再点顶部“用户账户”→“编辑权限” - 如果想授全局权限（如允许创建数据库），必须手动切到“全局权限”标签页，而不是依赖“数据库特权”部分
- Host 字段必须严格匹配：'
user@'localhost' 和 'user@'127.0.0.1' 是两个独立账号，改错一个就白忙
用 SHOW GRANTS 验证时，输出和预期不符怎么办？
SHOW GRANTS 是唯一可信的验证方式，但它容易被误读。例如执行 SHOW GRANTS FOR 'dev'@'localhost'; 返回：
GRANT USAGE ON *.* TO `dev`@`localhost`
这说明该账号目前没有任何实际权限（USAGE 仅表示存在，不包含任何操作权），哪怕你刚在界面上勾了一堆选项。
- 检查是否漏点了“执行”按钮——phpMyAdmin 不自动保存，必须手动点右下角“执行”
- 确认你没在“数据库特权”里选了错误的数据库名：大小写、下划线、反引号都要和
SHOW DATABASES输出完全一致 - 若目标数据库名含短横线（如
my-app），必须用反引号包裹：`my-app`，否则 phpMyAdmin 会静默失败 - MySQL 8.0+ 用户若启用了角色（ROLE），
SHOW GRANTS默认不显示角色内权限，需加USING role_name后缀
权限改了但应用连不上，是不是没生效？
连接失败 ≠ 权限未生效。更可能是权限类型不匹配。比如你给 'app'@'192.168.1.%' 授了 SELECT，但 PHP 应用配置里写的是 'app'@'localhost'，这两个账号互相不可见。
- 先查实际连接来源：
SELECT User, Host FROM mysql.user WHERE User = 'app';，确认 Host 值和应用配置一致 - 检查 MySQL 是否启用了
skip-name-resolve：若开启，'app'@'%'可匹配所有 IP，但'app'@'myapp.local'会失效 - 如果用 Docker 或云数据库，注意网络层可能做了源 IP 转换（如 NAT），真实 Host 可能是网关地址而非容器内网 IP
- phpMyAdmin 自身登录用的是
$cfg['Servers'][$i]['auth_type']配置的认证方式，和你授的用户权限无关，别混淆
FLUSH PRIVILEGES 到底还要不要执行？
在 phpMyAdmin 5.2 中，只要你是通过标准“编辑权限”流程操作（非直改 mysql.user 表），**不需要手动执行 FLUSH PRIVILEGES**。界面提交时已调用 GRANT 或 UPDATE 语句，MySQL 服务端会自动重载缓存。
但如果你做过这些事，就必须补：FLUSH PRIVILEGES：
- 直接在 SQL 标签页运行了
UPDATE mysql.user SET ... - 用命令行或其他工具（如 MySQL Workbench）改过系统表
- 怀疑权限表损坏，想强制重载全部缓存（极少数情况）
执行前先确认当前账号有 RELOAD 权限：SELECT Reload_priv FROM mysql.user WHERE User='your_user' AND Host='localhost';，返回 Y 才能成功。否则会卡在 “Access denied” 且无提示。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
