17370845950

绝大多数情况下GRANT后不用FLUSH PRIVILEGES；仅当直接修改mysql系统表时才必须执行，否则多余且可能掩盖真实问题，如连接未重连、主机名不匹配或认证插件不兼容等。

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(); 看看到底是以谁的身份连进来的——这比反复刷权限有用十倍。