GRANT后无需FLUSH PRIVILEGES，权限自动生效；常见连不上原因是未重连、主机名/插件不匹配或权限粒度导致生效延迟。
mysql权限改了却还是报 access denied，大概率不是你授权写错了，而是权限根本没“上身”——它卡在连接、缓存或匹配逻辑里了。
GRANT 之后到底要不要 FLUSH PRIVILEGES？
绝大多数情况下：不用，而且加了也没用。只要你是用 GRANT 或 REVOKE 改的权限，MySQL 会自动重载内存中的权限缓存，新连接立刻生效。手动执行 FLUSH PRIVILEGES 属于“多此一举”，还可能让你误以为“不刷就不生效”，从而忽略真正的问题点。
- 唯一必须用
FLUSH PRIVILEGES的场景：你绕过授权语法，直接UPDATE mysql.user或INSERT INTO mysql.db修改了系统表 - 如果不确定自己是否用了标准语句，可以查操作记录：
select * FROM mysql.general_log WHERE argument LIKE '%GRANT%' OR argument LIKE '%REVOKE%' ORDER BY event_time DESC LIMIT 5 -
GRANT后加FLUSH PRIVILEGES不报错，但属于“做了没用的事”
为什么刚授权的用户连不上？最常见三个坑
权限检查只发生在连接建立那一刻，已存在的连接不会动态更新权限——哪怕你刚给它加了 ALL PRIVILEGES。
- 当前连接仍持有旧权限，必须断开重连：
QUIT;后再mysql -u user -p -
'user'@'localhost'和'user'@'127.0.0.1'是两个完全不同的账号：前者走 unix socket，后者走 TCP/IP；授权时多一个空格（比如'user '@'localhost'）就匹配不上 - MySQL 8.0+ 默认认证插件是
caching_sha2_password，某些老客户端（如旧版 navicat、python MySQLdb）不兼容，会静默降级失败——连接成功但权限无效
不同粒度权限的生效时机完全不同
别指望“改完就能用”，权限生效不是统一触发的，得看你是授的哪一级：
-
GRANT SELECT ON db1.t1 TO 'u'@'h';→ 下次执行SELECT * FROM t1;就生效（表级权限，热更新） -
GRANT SELECT ON db1.* TO 'u'@'h';→ 下次执行USE db1;才生效（数据库级权限） -
GRANT SELECT ON *.* TO 'u'@'h';→ 必须断开重连（全局权限，只对新连接生效）
升级后权限异常？先看系统表和认证插件
MySQL 5.7 升级到 8.0 后，mysql.user 表结构大变：废弃了 Password 字段，新增 authentication_string 和 plugin 字段。如果没跑 mysqld --upgrade=FORCE，权限表字段缺失，GRANT 可能写不进底层，自然不生效。
- 检查字段是否完整：
DESC mysql.user;看有没有authentication_string、account_locked等 8.0 字段 - 确认关键用户插件是否兼容：
SELECT User, Host, plugin FROM mysql.user;，必要时回退：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 若用
--skip-grant-tables启动过，所有权限校验被跳过，此时GRANT根本不会写入表，任何刷新都无效
权限问题本质是元数据不一致或行为逻辑变更，不是单纯重启或刷新就能解决。最容易被忽略的，其实是连接复用和主机名精确匹配——连错账号、连着旧连接、连到另一个实例，都会让你对着正确的 SQL 干瞪眼。