FLUSH PRIVILEGES仅在直接UPDATE/INSERT权限表（如mysql.user）时真正必要；GRANT/ALTER USER等标准语句自动同步内存与磁盘，无需执行，且已存在连接须重连才生效。
FLUSH PRIVILEGES 什么时候真正必要？
只在你绕过标准 SQL 语句、直接用 UPDATE 或 INSERT 修改 mysql.user、mysql.db 等系统表时，FLUSH PRIVILEGES 才是必需的。MySQL 不会监听这些表的磁盘变更，内存里的权限缓存仍保持旧值——不刷，新设置就只是“躺在磁盘上”，对任何新连接都无效。
常见必须刷的场景包括：
UPDATE mysql.user SET authentication_string = PASSWORD('new') WHERE User='u1';INSERT INTO mysql.db VALUES ('localhost','db1','u1','Y','N','N',...);- 用
mysqldump导入一批权限记录后
GRANT / ALTER USER 后为什么通常不用 FLUSH PRIVILEGES？
因为 GRANT、REVOKE、CREATE USER、ALTER USER 这些语句在执行时，MySQL 会自动同步磁盘与内存：既写入系统表，也更新内存中的 ACL 缓存。从 MySQL 8.0.16 起，这种自动同步已稳定，无需额外刷新。
但要注意版本差异：
- MySQL 8.0.15 及更早版本中，
GRANT偶尔存在延迟，加FLUSH PRIVILEGES是保守做法 - MySQL 5.7 及以前，
SET PASSWORD不触发自动刷新，必须配FLUSH PRIVILEGES - 用
ALTER USER ... IDENTIFIED BY（推荐）则始终自动生效，不依赖刷新
执行了 FLUSH PRIVILEGES 却没生效？先查这几点
命令本身成功返回，不代表权限就“活”了。常见失效原因和排查点：
-
Host字段不匹配：比如GRANT ... TO 'u'@'localhost'，但客户端用127.0.0.1连——这是两个不同用户，和刷不刷无关 - 改错了表字段：误清空
authentication_string或设错account_locked，一刷就锁死该账号 - 主从不一致：在从库上直接改
mysql表再FLUSH PRIVILEGES，会导致复制中断或权限分裂 - 验证方式错误：用
SHOW GRANTS看的是当前会话权限快照，应配合CURRENT_USER()确认实际匹配的用户身份
它到底刷了什么？不是“刷新权限”，而是“重载缓存”
FLUSH PRIVILEGES 的本质动作是：丢弃内存中所有已缓存的权限数据（包括 mysql.user、mysql.db、mysql.tables_priv 等 6 张核心表），然后从磁盘完整读取并重建整个 ACL 缓存。这是一个原子性全量覆盖操作，没有增量逻辑。
关键影响有两层：
- 只影响后续新建连接——已存在的连接仍按旧权限运行，必须重连才感知变更
- 不校验数据合法性：如果磁盘上的权限表本身字段错乱（如
authentication_string格式不对），刷完照样加载，可能直接导致登录失败
真正需要它的时候越来越少；一旦要用，得先确保磁盘上的数据本身是对的——它只是个“重载信号”，不是纠错工具。
