根本原因是MySQL将用户身份（User+Host）与权限完全分离管理，改密码不自动继承或同步权限，且需手动执行FLUSH PRIVILEGES并确保Host匹配、RELOAD权限可用及角色正确激活。
在 phpMyAdmin 5.2 中修改密码后权限不足，根本原因不是密码改错了，而是你改的是「账号凭证」，但没动「权限配置」——MySQL 把用户身份（User+Host）和权限（存于 mysql.user 等表）完全分开管理。改完密码，旧权限不会自动继承，甚至可能因 Host 不匹配直接失效。
为什么改密码后连 SELECT 都被拒绝？
常见现象是：用新密码登录 phpMyAdmin，能进首页，但点开数据库就报 Access denied for user 'appuser'@'localhost' 或直接空白；或者执行 SQL 时提示 SELECT command denied。这不是密码问题，而是权限未绑定到新用户记录上。
-
ALTER USER 'appuser'@'localhost' IDENTIFIED BY 'newpass'只更新了认证字段（authentication_string），不触碰任何权限字段（如Select_priv、Insert_priv） - 如果你之前是用
'appuser'@'%'登录的，但新密码只设给了'appuser'@'localhost'，那从远程连接就会 fallback 到无权限的匿名用户或拒绝连接 - MySQL 8.0+ 默认启用
caching_sha2_password插件，而旧客户端或 phpMyAdmin 5.2 某些版本可能未正确协商，导致看似登录成功，实则权限降级
phpMyAdmin 5.2 密码修改界面为何“不保存权限”？
phpMyAdmin 的图形化密码修改入口（在“用户账户”页点击编辑 → “更改密码”）底层只执行 ALTER USER ... IDENTIFIED BY，它不检查也不同步该用户当前在 mysql.db、mysql.tables_priv 中的授权状态。尤其当你用 root 改其他用户密码时，更不会帮你补全权限。
- 该界面不显示“全局权限”“数据库权限”等复选框，意味着它压根不处理权限字段
- 如果你之前是用
GRANT SELECT ON mydb.* TO 'u'@'h'授权的，改密码后这条 GRANT 依然存在，但必须确保FLUSH PRIVILEGES已执行（否则缓存未更新） - phpMyAdmin 5.2 的“执行”按钮只提交密码语句，不会自动追加
FLUSH PRIVILEGES—— 这步必须手动补
执行 FLUSH PRIVILEGES 后仍没权限？查这三点
看到 0 行受影响 不代表权限已生效，只是命令被接受。真正卡住的往往是以下细节：
- 当前登录账号没有
RELOAD权限：运行SELECT Reload_priv FROM mysql.user WHERE User='your_user' AND Host='localhost'，确认返回Y；否则换 root 执行 - Host 字段严格不匹配：用
SHOW GRANTS FOR 'appuser'@'localhost'查实际绑定的 host，注意'appuser'@'127.0.0.1'和'appuser'@'localhost'是两个独立条目，权限需分别授予 - MySQL 8.0+ 角色未激活：如果用了
CREATE ROLE r1; GRANT SELECT ON mydb.* TO r1;，还必须GRANT r1 TO 'appuser'@'localhost'; SET DEFAULT ROLE r1 TO 'appuser'@'localhost';，否则FLUSH PRIVILEGES无效
最易被忽略的是：phpMyAdmin 5.2 在非 root 账号下修改密码后，不会刷新左侧数据库列表的权限视图，你得手动 F5 页面，或切换到“用户账户”页再点一次“刷新”按钮（如果可见）——这个 UI 缓存和 MySQL 内存缓存是两回事，都得清。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
