flush privileges 仅在直接修改 mysql.user 表（如 update）时必需；使用 alter user 或 set password 无需执行，否则可能掩盖错误、破坏主从一致性或加载损坏权限数据。
不需要执行 FLUSH PRIVILEGES —— 除非你直接改了 mysql.user 表。
用 ALTER USER 或 SET PASSWORD 改密，FLUSH PRIVILEGES 是冗余操作
MySQL 5.7.6 起，ALTER USER 'u'@'h' IDENTIFIED BY 'p' 会自动同步磁盘与内存权限缓存；8.0.16+ 更彻底，不存在“延迟生效”问题。此时执行 FLUSH PRIVILEGES 不但没效果，还可能掩盖真实错误：
- 如果
ALTER USER因用户不存在或语法错失败了，FLUSH PRIVILEGES却成功返回，你会误以为密码已更新 - 在主从架构中，从库上误执行该命令，会导致权限状态与主库不一致，复制线程可能中断
-
FLUSH PRIVILEGES本身不校验权限表结构，若mysql.user中authentication_string字段被清空或类型错，它会直接加载坏数据，连root都登不上
只有直接 UPDATE mysql.user 才真需要 FLUSH PRIVILEGES
这类操作绕过了 MySQL 的权限管理接口，只写磁盘、不通知内存。例如：
UPDATE mysql.user SET authentication_string = PASSWORD('new') WHERE User='u';
这种写法在 MySQL 8.0+ 已不推荐（PASSWORD() 函数被移除），且必须配 FLUSH PRIVILEGES 才能让新密码对新连接生效。常见高危场景包括：
- 用脚本批量
INSERT INTO mysql.db或REPLACE INTO mysql.tables_priv - 用
mysqldump导入权限表备份后，没走GRANT流程 - 手动编辑
mysql.user的account_locked或password_expired字段（这些字段受内部逻辑保护，UPDATE可能被忽略）
改完密码还是连不上？先排查匹配逻辑，不是缓存没刷
90% 的“密码不生效”问题，根本不是缓存问题，而是账号没匹配上：
-
'u'@'localhost'和'u'@'127.0.0.1'是两个独立账号，改了前者，用后者登录当然无效 - 本地 socket 连接默认匹配
'u'@'localhost'，但你改的是'u'@'%'—— 查权限要用：SELECT user, host, plugin FROM mysql.user WHERE user = 'u'; - 登录后执行
SELECT CURRENT_USER();，确认实际绑定的是哪一行；再比对SHOW GRANTS FOR CURRENT_USER(); - MySQL 8.0 默认认证插件是
caching_sha2_password，老版客户端（如旧版 Connector/J）不支持，报错类似Plugin caching_sha2_password could not be loaded
已存在的连接不会重载权限，重连才是关键动作
FLUSH PRIVILEGES 只影响新建立的连接。当前会话的权限快照在登录瞬间就固化了，即使你刚刷新了权限，当前连接仍按旧权限运行。验证是否生效的唯一可靠方式是：
- 新开终端，执行：
mysql -u u -p，输入新密码尝试登录 - 不要复用已有连接做测试，那永远看不到变化
- 如果连不上，先确认目标账号是否存在、host 是否匹配、认证插件是否兼容，而不是立刻去刷权限
真正容易被忽略的，是你改的那条记录是否真的被匹配到了——很多“不生效”，根本不是缓存没刷，而是 host 写成了 '%' 却试图从 localhost socket 连接。
