mysql中使用FLUSH PRIVILEGES刷新权限表

只有在直接修改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';
  FLUSH PRIVILEGES;

• ❌ 错误习惯：

  GRANT select ON mydb.* TO 'test'@'%';
  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 不是开关，而是“重载配置”的信号 —— 发出前得确保磁盘上的表数据本身是对的。