MySQL修改权限后为什么必须执行FLUSH PRIVILEGES

FLUSH PRIVILEGES 并非必须，仅在绕过权限接口（如直接UPDATE mysql.user）时才需执行；GRANT/ALTER USER等标准操作会自动同步内存与磁盘，无需手动刷新。

FLUSH PRIVILEGES 不是“必须”，而是你绕过了 MySQL 的权限管理接口才被迫需要它。

直接 UPDATE mysql.user 后必须执行 FLUSH PRIVILEGES

• MySQL 内存中维护着一份权限缓存（如 acl_users 数组），启动时从磁盘加载一次，之后所有鉴权都查内存
• UPDATE mysql.user SET authentication_string = PASSWORD('new') WHERE User='u'; 这类 DML 只改磁盘，不通知内存，缓存仍为旧值
• 此时不执行 FLUSH PRIVILEGES，新连接也会用旧权限，甚至可能连不上（比如密码字段写错格式）
• 常见高危操作包括：用脚本批量 INSERT INTO mysql.db、mysqldump 导入权限表后没走标准流程

GRANT 或 ALTER USER 后执行 FLUSH PRIVILEGES 是冗余且危险的

• MySQL 5.7.6+ 中，GRANT SELECT ON db.* TO 'u'@'%'; 和 ALTER USER 'u'@'%' IDENTIFIED BY 'p'; 会自动同步磁盘与内存，无需额外命令
• 如果 ALTER USER 因语法错误或权限不足失败了，FLUSH PRIVILEGES 却成功返回，你会误以为改密成功
• 在主从架构中，从库上误执行 FLUSH PRIVILEGES 会导致权限状态与主库分裂，复制可能中断

执行了 FLUSH PRIVILEGES 还是不生效？先排查这几点

• 已存在的连接不会重载权限：当前会话的权限快照在登录瞬间就固化了，必须 QUIT 后重连才感知变更
• 'u'@'localhost' 和 'u'@'127.0.0.1' 是两个独立账号，改了前者，用后者登录当然无效
• 客户端不支持认证插件：MySQL 8.0 默认用 caching_sha2_password，老版 Connector/J 或某些 ORM 可能不兼容，报错类似 Plugin caching_sha2_password could not be loaded
• 没有 RELOAD 权限：普通用户执行 FLUSH PRIVILEGES 会直接报错 ERROR 1227 (42501): Access denied

真正容易被忽略的，是你改的那条记录是否真的被匹配到了——用 SELECT user, host, plugin FROM mysql.user WHERE user = 'xxx'; 查完，再在目标连接里执行 SELECT CURRENT_USER();，确认实际绑定的是哪一行。很多“不生效”，根本不是缓存没刷，而是 host 写成了 '%' 却试图从 localhost socket 连接。