GRANT后权限不生效，绝大多数情况无需FLUSH PRIVILEGES；MySQL会自动重载缓存，新连接立即生效，但已存在连接需断开重连，且不同粒度权限（表级、库级、全局）生效时机各不相同。
GRANT 后权限不生效，绝大多数情况根本不用 FLUSH PRIVILEGES
MySQL 5.7 及以后版本（包括 8.0）中，只要用标准 GRANT 或 REVOKE 语句授予权限，MySQL 就会自动重载权限缓存——新连接立刻生效。FLUSH PRIVILEGES; 不是“保险操作”，而是“急救手段”：它只在你绕过授权语法、直接 UPDATE mysql.user 或 INSERT INTO mysql.db 修改系统表时才真正必要。
常见误操作：
- 执行
GRANT SELECT ON mydb.* TO 'u'@'localhost';后紧跟FLUSH PRIVILEGES;→ 语法合法，但纯属冗余 - 误以为“不刷就不生效”，结果忽略了真实问题（比如没重连、连错实例、主机名拼错）
- 在主从架构里只在从库执行
GRANT→ 权限写不进主库 binlog，从库刷新也无效
为什么刚 GRANT 完还是 Access denied？关键在连接生命周期
MySQL 的权限检查只发生在连接建立那一刻。已存在的连接不会动态感知权限变更——哪怕你刚给它加了 ALL PRIVILEGES，当前会话仍按旧权限运行。
必须断开重连才能生效：
- 在客户端执行
QUIT;或EXIT; - 重新运行
mysql -u u -p -h localhost（注意：'u'@'localhost'和'u'@'127.0.0.1'是两个完全不同的账号） - 应用服务需重建数据库连接池，不能只靠重启进程而不重置连接
若重连后仍报错，优先检查是否连到了目标实例：本地可能同时跑着 Docker、Homebrew、系统自带多个 MySQL，mysql -u u -p 默认走 socket，而你改权限的可能是 mysql -h 127.0.0.1 -P 3307 那个。
不同粒度权限的生效时机完全不同
别指望“改完就能用”，权限生效不是统一触发的，得看你是授的哪一级：
-
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';→ 必须断开重连（全局权限，只对新连接生效）
验证是否真生效，别只信 SHOW GRANTS FOR 'u'@'h';，要真跑一句 SELECT 或 INSERT 看报错；否则容易被“权限显示存在但实际不可用”的假象误导。
FLUSH PRIVILEGES 真正该用的唯一场景
只有当你没走授权语法，而是直接操作 mysql 系统表时，FLUSH PRIVILEGES; 才起作用：
-
UPDATE mysql.user SET Select_priv = 'Y' WHERE User = 'u';→ 必须配FLUSH PRIVILEGES;，否则内存缓存永远不更新 -
INSERT INTO mysql.db (Host, Db, User, Select_priv) VALUES ('%', 'mydb', 'u', 'Y');→ 同样必须刷新
如果不确定自己是否用了标准语句，查操作历史：SELECT * FROM mysql.general_log WHERE argument LIKE '%GRANT%' OR argument LIKE '%REVOKE%' ORDER BY event_time DESC LIMIT 5;。另外，若 MySQL 正以 --skip-grant-tables 启动，所有权限校验被跳过，此时 GRANT 根本不会写入表，任何刷新都无效——先确认 SELECT @@skip_grant_tables; 返回值是否为 OFF。
