根本原因是权限未显式授予并刷新，MySQL权限系统需手动执行GRANT语句+FLUSH PRIVILEGES生效；phpMyAdmin建用户仅写入mysql.user表，数据库级权限（如SELECT）必须在目标数据库权限页勾选并点击“执行”，或用匹配User@Host的GRANT语句授权。
新建用户后执行 SELECT 报错 #1044 - Access denied for user
根本原因不是用户没建成功，而是权限没刷进 mysql 权限系统。phpmyadmin 的「用户账户」页创建用户时，默认只写入 mysql.user 表，但数据库级权限（比如对 myapp_db 的 select）必须显式授予并刷新。常见表现是：用户能登录 phpmyadmin，但点开指定数据库就提示拒绝访问，或者执行查询直接报错。
解决方法很直接：
- 在 phpMyAdmin 左侧导航栏，先点击目标数据库（如
myapp_db） - 顶部切换到
权限标签页 → 点击添加用户账户右侧的编辑权限（不是重新建用户） - 在「数据库特定权限」区域，确认已勾选所需权限（至少
SELECT、INSERT等），并确保「数据库」下拉框选中的是当前数据库名，不是全局 - 务必点击页面最下方的
执行（不是「保存」或「返回」）——这步会触发FLUSH PRIVILEGES
用 SQL 手动授予权限时 GRANT 语句不生效
手动执行 GRANT 后仍报错，大概率是权限作用域写错了。MySQL 的权限分层级，GRANT SELECT ON myapp_db.* TO 'user1'@'localhost' 和 GRANT SELECT ON *.* TO 'user1'@'localhost' 完全不同。前者只对 myapp_db 生效，后者才是全局。
更隐蔽的问题是主机名匹配：如果用户是用 'user1'@'%' 创建的，但你执行的是 GRANT ... TO 'user1'@'localhost'，权限不会叠加，MySQL 会按 user@host 元组精确匹配。
安全且稳妥的做法：
立即学习“PHP免费学习笔记（深入）”；
- 先查清楚用户真实 Host：
SELECT User, Host FROM mysql.user WHERE User = 'user1'; - 按查出的
Host值写GRANT，例如：GRANT SELECT, INSERT ON `myapp_db`.* TO 'user1'@'%'; - 立刻执行：
FLUSH PRIVILEGES;（phpMyAdmin 的 SQL 页可直接运行） - 注意数据库名含特殊字符（如短横线）必须用反引号包裹：
`my-app-db`
用户能进数据库但看不到表，或表列表为空
这通常不是权限缺失，而是 phpMyAdmin 的「数据库导航」默认只显示该用户有 SELECT 权限的表。如果只给了 CREATE 或 DROP 权限，表名也不会出现。
验证方式：在 SQL 页手动执行 SHOW TABLES IN myapp_db;。如果返回结果正常，说明权限实际存在，只是 phpMyAdmin 的 UI 过滤太严。
临时绕过方法：
- 给用户追加
SELECT权限（哪怕只读也够显示表名） - 或者，在 phpMyAdmin 设置里关闭严格表权限检查（不推荐生产环境）：
$cfg['Servers'][$i]['DisableIS'] = true;（需改配置文件）
从其他服务器导入用户权限后，本地 phpMyAdmin 不认
跨服务器迁移时，常有人导出 mysql.user 表数据再导入，但这会导致权限失效。因为 MySQL 8.0+ 使用缓存权限，且 mysql.db、mysql.tables_priv 等表也要同步，手工维护极易遗漏。
正确做法永远是重放 GRANT 语句，而不是复制系统表数据：
- 在源服务器运行：
SHOW GRANTS FOR 'user1'@'%'; - 把输出的每条
GRANT ...语句复制到目标服务器执行 - 最后补一句
FLUSH PRIVILEGES; - 特别注意：MySQL 8.0 默认认证插件是
caching_sha2_password，如果目标是旧版本，可能需要加IDENTIFIED WITH mysql_native_password
权限系统的细节藏在 User 和 Host 的组合里，少一个字符匹配不上，整个权限链就断了。别信「建了用户就该有库权限」这种直觉，MySQL 的权限模型是显式授权制，没有默认继承。
