什么时候必须用 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不是开关，而是“重载配置”的信号 —— 发出前得确保磁盘上的表数据本身是对的。
