FLUSH PRIVILEGES 强制 MySQL 从磁盘重载权限表并覆盖内存 ACL，仅影响新建连接；仅在直接 DML 修改系统表时必需，标准授权语句无需执行。
FLUSH PRIVILEGES 到底干了什么？
它不是“让权限生效”的万能开关，而是强制 MySQL 从磁盘重新读取 mysql.user、mysql.db、mysql.tables_priv 等权限表，并完全覆盖内存中缓存的 ACL（访问控制列表）——相当于把权限缓存“重装一遍”。这个过程不重启服务，但只影响后续新建的连接；已存在的连接仍按旧权限运行，必须重新登录才感知变更。
什么时候必须执行 FLUSH PRIVILEGES？
仅在你绕过标准语法、直接用 DML 操作系统表时才需要。比如：
-
UPDATE mysql.user SET authentication_string = PASSWORD('newpass') WHERE User = 'test';→ 必须跟FLUSH PRIVILEGES; -
INSERT INTO mysql.db ...或DELETE FROM mysql.proxies_priv→ 同样必须刷新 - 用文本编辑器或工具直接改了
mysql库的 .ibd 文件（极不推荐）→ 也得靠它通知 MySQL 重载
反之，用 CREATE USER、GRANT、REVOKE、ALTER USER 等语句修改权限或密码时，MySQL 自动同步磁盘+内存，执行 FLUSH PRIVILEGES 不但多余，还可能掩盖语法错误。
为什么有时候刷了也不生效？常见踩坑点
很多人一遇到权限不生效就下意识 FLUSH PRIVILEGES，结果白忙活甚至引发事故：
-
host 匹配失败：比如
GRANT ... TO 'u'@'localhost'，但客户端用127.0.0.1连——这是两个不同 host，和刷不刷无关 -
权限表改错了：手误清空
authentication_string或写错Host字段，一刷就立刻锁死 root 登录 -
主从不一致：在从库上直接改
mysql表再FLUSH，导致主从权限分裂，复制可能报错 -
没检查当前会话视角：用
SHOW GRANTS;看的是当前连接的权限快照，不是全局最新状态；应配合CURRENT_USER()确认实际匹配的用户身份
更安全、更现代的替代方案
直接操作 mysql 系统表是最后手段。MySQL 5.7.6+ 起，优先走语义明确、原子安全的标准路径：
- 建用户：
CREATE USER 'u'@'h' IDENTIFIED BY 'p'; - 赋权：
GRANT SELECT ON db.* TO 'u'@'h'; - 改密：
ALTER USER 'u'@'h' IDENTIFIED BY 'newp';（比SET PASSWORD更推荐） - 回收：
REVOKE INSERT ON db.t FROM 'u'@'h';，而不是DELETE FROM mysql.user
真正需要 FLUSH PRIVILEGES 的场景，越来越少；而一旦要用，就得先确保磁盘上的数据本身是对的——它只是个“重载信号”，不是纠错工具。
