GRANT 之后还用不用 FLUSH PRIVILEGES？
绝大多数情况下——不用。只要你是用
GRANT或
REVOKE命令修改权限，MySQL 会自动重载内存中的权限缓存，新连接立刻生效。手动执行
FLUSH PRIVILEGES;不但多余，还可能掩盖真正的问题。 只有当你绕过授权语法、直接
UPDATE mysql.user或
INSERT INTO mysql.db修改系统表时，才必须执行
FLUSH PRIVILEGES;
GRANT后加
FLUSH PRIVILEGES;不报错，但属于“做了没用的事”，容易让人误以为“不刷就不生效”，从而忽略主机名、连接复用等真实原因 如果你不确定是否用了标准授权语句，可以查一下操作历史：
SELECT * FROM mysql.general_log WHERE argument LIKE '%GRANT%' OR argument LIKE '%REVOKE%' ORDER BY event_time DESC LIMIT 5;
为什么刚授权的用户还是 “Access denied”？
最常见不是权限没写对，而是连接没“换人”。MySQL 的权限检查发生在连接建立那一刻，已存在的连接不会动态更新权限——哪怕你刚给它加了
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，某些客户端老版本不兼容，会静默降级失败
改了 mysql.user 表但权限死活不生效
这是唯一真正需要
FLUSH PRIVILEGES;的场景，但也最容易出错——因为改表本身就有风险。 直接
UPDATE mysql.user后，必须执行
FLUSH PRIVILEGES;，否则内存缓存仍是旧值 MySQL 8.0 起密码字段是
authentication_string，不再是
password；误更新错字段会导致账号变“空密码”或认证失败 改完别忘了检查
host字段是否大小写一致（Linux 系统下
'ROOT'@'localhost'≠
'root'@'localhost'） 如果用的是
--skip-grant-tables启动，所有权限校验被跳过，此时
GRANT语句根本不会写入表，任何刷新都无效
权限改了，但 USE db_name 后还是没权限？
MySQL 对不同粒度权限的生效时机不同，不是所有变更都等下次连接——有些在当前连接里就能“热更新”，但有严格前提。
GRANT SELECT ON db1.* TO 'u'@'h';→ 下次执行
USE db1;才生效（数据库级权限）
GRANT SELECT ON db1.t1 TO 'u'@'h';→ 下次对该表发起查询（如
SELECT * FROM t1;）即生效（表级权限）
GRANT SELECT ON *.* TO 'u'@'h';→ 必须断开重连（全局权限） 所以测试时别只做一次查询就下结论，先
USE切库，再查表，再试 DML，才能覆盖全路径
真正卡住人的往往不是命令会不会写，而是“以为改完了，其实连接还挂着旧上下文”，或者“授权给了
%却从
localhost连，结果匹配到空用户或匿名用户”。遇到不生效，先
SELECT USER(), CURRENT_USER();看看到底是以谁的身份连进来的——这比反复刷权限有用十倍。
