执行成功≠权限立刻可用，主因是权限未匹配当前连接身份或旧连接未重连：先查select user(), current_user()确认认证账号，再show grants for current_user()验真实权限，最后必须退出重连才能生效。
执行成功 ≠ 权限立刻可用，绝大多数情况是权限没匹配到当前连接身份，或旧连接还挂着旧权限上下文。
用户登录后 SHOW DATABASES 只见系统库
这说明权限表里确实写了记录，但 MySQL 没把它算进当前会话。最常见原因有三个：
-
CURRENT_USER()和USER()不一致：前者是你真正被认证的账号（比如'app'@'192.168.1.100'），后者是你“声称”的身份（比如'app'@'%'）。用SELECT USER(), CURRENT_USER();一眼就能看出差别 - 只给了
SELECT ON mydb.*，那SHOW DATABASES就只能看到mydb和系统库；想看到所有库，得有SELECT ON *.*或至少SELECT ON mysql.*（否则连mysql库都不可见） - 用户从
127.0.0.1连，但授权写的是'user'@'localhost'——这两个在 MySQL 里是完全不同的账号，localhost走 socket，127.0.0.1走 TCP，不会 fallback
GRANT 后不重连，权限就等于没给
MySQL 权限检查只发生在连接建立那一刻。已存在的连接不会动态更新权限，哪怕你刚执行完 GRANT 并 FLUSH PRIVILEGES。
- 必须退出客户端再重新登录，比如在命令行敲
EXIT;，再跑一遍mysql -u user -p -h 192.168.1.100 -
FLUSH PRIVILEGES对GRANT语句本身是冗余的：5.7+ 版本中，GRANT会自动同步磁盘和内存，加了它也不会让旧连接变新权限 - 如果加了
FLUSH PRIVILEGES才“看起来生效”，大概率是你忘了重连，或者压根连错了实例（比如本地 Docker 容器和宿主机 MySQL 混了）
远程连不上？先看 bind-address 和认证插件
授权写得再全，TCP 包进不来，或者握手阶段就断了，权限就是纸面空谈。
- 检查
/etc/mysql/mysql.conf.d/mysqld.cnf中bind-address是否还是127.0.0.1；改成0.0.0.0或注释掉，然后sudo systemctl restart mysql - 验证监听是否生效：
ss -tln | grep :3306输出里要有*:3306或0.0.0.0:3306，不能只有127.0.0.1:3306 - MySQL 8.0+ 默认用
caching_sha2_password插件，但老客户端（如 Navicat 12、JDBC 8.0 以前）可能静默失败——表现是能连上，一查库就断。临时解法：ALTER USER 'user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';
账户被锁或权限粒度没对上
这些点容易被跳过，因为错误提示根本不提它们。
- 查状态：
SELECT User, Host, account_locked FROM mysql.user WHERE User = 'user';，如果account_locked是Y，权限再全也白搭 - 授的是表级权限（如
GRANT SELECT ON db.t TO 'u'@'h';），那对这张表的查询立刻生效；但如果是全局权限（如GRANT SELECT ON *.* TO 'u'@'h';），只对新连接生效，当前连接无论怎么USE db都看不到效果 - 云环境别只开系统防火墙（如
ufw），安全组/网络 ACL 必须放行3306入方向
真正卡住的地方，往往不是 SQL 写错了，而是你连的不是你以为的那个账号，或者连的不是你以为的那个 MySQL 实例。验证前先确认 CURRENT_USER() 和监听地址，比反复 GRANT 有用得多。
