FLUSH PRIVILEGES仅在直接UPDATE mysql.user等系统表后必需，ALTER USER/SET PASSWORD等标准操作自动同步磁盘与内存，执行它多余且可能掩盖错误；权限对新连接生效，旧连接须重连。
不是必须，而是你用了错误的修改方式才“看起来必须”。 用 ALTER USER 或 SET PASSWORD 改密，MySQL 会自动同步磁盘和内存，FLUSH PRIVILEGES 完全多余；只有直接 UPDATE mysql.user 才真需要它——但这种操作本身就不该出现在生产环境。
哪些改密码操作之后必须 FLUSH PRIVILEGES？
仅当绕过语义化权限语句、直接写系统表时才触发这个需求：
-
UPDATE mysql.user SET authentication_string = '$A$...'（手动更新哈希值） -
UPDATE mysql.user SET password_expired = 'Y'等字段后未走标准流程 - 用
mysqldump导入了修改过的mysql.user表
这些操作 MySQL 完全不感知，内存 ACL 缓存仍是旧的，不 FLUSH PRIVILEGES 就永远不生效。
为什么 ALTER USER 后执行 FLUSH PRIVILEGES 是错觉？
很多人在 ALTER USER 'u'@'h' IDENTIFIED BY 'p'; 后顺手敲了 FLUSH PRIVILEGES，发现“生效了”，其实生效的是 ALTER USER 本身——FLUSH 只是碰巧没报错，纯属冗余。更危险的是：如果 ALTER USER 因语法或权限问题失败了，FLUSH 会掩盖这个错误，让你误以为改成功了。
MySQL ≥8.0.16 中，ALTER USER 已完全原子化，改完立刻写磁盘+刷内存，无需任何额外命令。
执行了 FLUSH PRIVILEGES 还是连不上？常见陷阱
这不是命令失效，而是权限模型本身的限制：
- 已存在的连接不会重载权限——每个连接登录瞬间就固化了权限快照，
FLUSH不影响它，必须让客户端断开重连 -
'u'@'localhost'和'u'@'127.0.0.1'是两个独立账号，改了前者，用后者连当然无效 - MySQL 8.0 默认用
caching_sha2_password插件，如果客户端不支持（比如老版 MySQL Connector/J），连都连不上，跟刷不刷权限无关 - 执行
FLUSH PRIVILEGES需要RELOAD权限，普通用户执行会直接报错ERROR 1227 (42501): Access denied
真正容易被忽略的点：你改的到底是不是正在匹配的那个账号？用 SELECT user, host, plugin FROM mysql.user WHERE user = 'xxx'; 查完，再用 CURRENT_USER() 确认当前会话实际绑定的是哪条记录——很多“不生效”问题，根源是 host 匹配偏差，而不是缓存没刷新。
