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 干瞪眼。
