只有在直接修改mysql系统库权限表后才需执行FLUSH PRIVILEGES；使用CREATE USER、GRANT等标准语句则自动同步，无需手动刷新。
什么时候必须用 FLUSH PRIVILEGES
只有在**直接修改 mysql 系统库的权限表**（如 user、db、tables_priv）后，才需要执行 FLUSH PRIVILEGES。MySQL 启动时会将这些表加载进内存缓存，后续的权限检查都基于内存副本，不实时读表。
如果你是用 CREATE USER、GRANT、DROP USER 这类标准语句操作权限，MySQL 会自动同步内存缓存，完全不需要手动 FLUSH PRIVILEGES。
- ✅ 正确场景：
UPDATE mysql.user SET authentication_string = PASSWORD('newpass') WHERE User = 'test';<br>FLUSH PRIVILEGES; - ❌ 错误习惯：
GRANT SELECT ON mydb.* TO 'test'@'%';<br>FLUSH PRIVILEGES; ← 多余，且可能掩盖 GRANT 语法错误
FLUSH PRIVILEGES 的实际影响范围
它强制 MySQL 重新从磁盘读取所有权限表，并重建内存中的授权缓存。这个过程会短暂阻塞新连接的权限验证（不影响已建立连接），但不会中断现有会话。
- 只刷新权限相关表：
user、db、host、tables_priv、columns_priv、procs_priv、proxies_priv - 不刷新其他系统状态：比如变量设置（
SET GLOBAL）、查询缓存、表缓存等 - 不解决连接失败问题：如果
ERROR 1045 (28000)报错，先确认用户名/主机/IP是否匹配user.Host字段，而不是盲目刷权限
常见误用导致的问题
很多人把 FLUSH PRIVILEGES 当成“万能修复指令”，结果反而引入风险：
- 权限丢失：如果手误改错了
mysql.user表（比如清空了authentication_string），再FLUSH就立刻失效，root 都可能无法登录 - 权限未生效却归咎于没刷：比如
GRANT里用了'user'@'localhost'，但客户端连的是127.0.0.1—— 这是两个不同 host，和刷不刷权限无关 - 主从不一致：直接改从库的
mysql表并FLUSH，会导致主从权限状态分裂；应始终在主库用GRANT，靠复制同步
替代方案与安全建议
绕过直接改表 + FLUSH 的更安全路径：
- 新增用户优先用：
CREATE USER 'u'@'h' IDENTIFIED BY 'p'; GRANT ...; - 改密码统一用：
ALTER USER 'u'@'h' IDENTIFIED BY 'newp';（MySQL 5.7.6+）或SET PASSWORD FOR 'u'@'h' = PASSWORD('p'); - 回收权限用：
REVOKE ... FROM 'u'@'h';，不是DELETE FROM mysql.user - 真要查权限缓存是否更新？用
SELECT CURRENT_USER();和SHOW GRANTS;验证当前会话视角，比猜更可靠
直接操作 mysql 系统表是最后手段，FLUSH PRIVILEGES 不是开关，而是“重载配置”的信号 —— 发出前得确保磁盘上的表数据本身是对的。
