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