FLUSH PRIVILEGES仅在直接DML修改mysql系统表（如UPDATE mysql.user）时必需，它强制全量重载磁盘权限表覆盖内存ACL，不影响已存在连接，新权限需重新登录才生效；用ALTER USER、GRANT等标准语句则自动同步，执行该命令多余且可能掩盖错误。
不是必须，绝大多数情况下完全不需要执行 FLUSH PRIVILEGES —— 只有直接改系统表时才真需要它。
用 ALTER USER 或 SET PASSWORD 改密后，为什么还看到有人刷权限？
这是历史惯性 + 版本混用导致的误解。MySQL 5.7.6 起，ALTER USER 和 SET PASSWORD 已自动同步磁盘与内存权限缓存；8.0.16+ 更彻底，连“可能延迟”的边缘情况都修复了。此时执行 FLUSH PRIVILEGES 不但多余，还会掩盖真实问题：
- 如果改密失败（比如语法错、用户不存在），
FLUSH PRIVILEGES成功返回会让人误以为“操作完成了” - 若权限表本身被意外破坏（如字段类型错、
authentication_string被清空），FLUSH PRIVILEGES会直接加载坏数据，导致 root 都登不上 - 在主从架构中，从库上误刷会导致权限状态与主库分裂，复制线程可能报错中断
什么情况下 FLUSH PRIVILEGES 真的不可跳过？
只有一种场景：你绕过了所有 SQL 授权语句，用 DML 直接操作了 mysql 库下的表。比如：
UPDATE mysql.user SET authentication_string = PASSWORD('xxx') WHERE User='u1';INSERT INTO mysql.db (Host, Db, User, Select_priv) VALUES ('%', 'testdb', 'u1', 'Y');- 用
mysqldump导入了一套权限表备份，或用脚本批量更新了mysql.tables_priv
这些操作只写磁盘，MySQL 内存里的 ACL 缓存（ACL_USER 数组、ACL_DB 链表等）完全没感知，不刷就永远不生效。
FLUSH PRIVILEGES 到底做了什么？
它不是“让权限生效”的开关，而是强制重载信号：清空内存中全部权限缓存，再从磁盘完整读取 mysql.user、mysql.db、mysql.tables_priv 等 6 张核心表，重建整个 ACL 结构。这个过程是原子性的全量覆盖，没有增量逻辑。
- 只影响新建立的连接；已存在的连接仍按旧权限运行，必须重连才感知变更
- 不重启 mysqld，毫秒级完成，适合生产环境紧急修复
- 如果权限表损坏（如
user表被设为只读），FLUSH PRIVILEGES会直接报错：ERROR 1036: Table 'user' is read only
验证改密是否真正生效的正确姿势
别只看命令是否成功返回，要验证实际效果：
- 用
CURRENT_USER()确认你连接匹配的是哪个'user'@'host'条目（注意'localhost'和'127.0.0.1'是两个不同 host） - 新开一个终端，用新密码尝试登录：
mysql -u u1 -p，而不是复用当前会话 - 检查权限快照是否更新：
SHOW GRANTS FOR 'u1'@'%';（注意不是SHOW GRANTS;，后者只显示当前会话权限）
真正容易被忽略的点是：权限变更永远只对新连接生效，而人总爱在同一个终端里反复试 —— 这时候无论刷多少次 FLUSH PRIVILEGES，当前会话的权限都不会变。
