MySQL修改权限后为何必须执行FLUSH PRIVILEGES？

许多 MySQL 用户在修改权限后常常困惑：究竟是否需要执行 FLUSH PRIVILEGES？答案其实很简单——取决于修改方式。如果通过标准命令（如 GRANT、ALTER USER）进行操作，无需手动刷新；但若直接操作 mysql.user 表，则必须执行该命令。

简而言之：FLUSH PRIVILEGES 并非“必选项”，仅在绕过 MySQL 标准权限管理接口时才被迫需要它。

直接操作 mysql.user 表后必须执行 FLUSH PRIVILEGES

• MySQL 在内存中维护了权限缓存（例如 acl_users 数组），启动时从磁盘加载一次，之后所有认证均基于内存，不再读取磁盘。
• 执行 UPDATE mysql.user SET authentication_string = ... WHERE User='u'; 仅更新了磁盘记录，内存缓存仍为旧数据。
• 此时若不执行 FLUSH PRIVILEGES，新连接将沿用旧权限，甚至可能因密码格式错误而无法连接。
• 常见高风险操作包括：通过脚本批量 INSERT INTO mysql.db，或从 mysqldump 导入权限表后未遵循标准流程。这种情况下，FLUSH PRIVILEGES 就是必要的补救措施。

使用 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 后仍未生效？请检查以下常见问题

• 已有连接不会重新加载权限：每个会话的权限快照在登录时即固定，必须断开并重新连接才能生效。这是设计特性，并非缺陷。
• '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 连接，导致无法匹配对应记录。