FLUSH PRIVILEGES 强制从磁盘重新加载 mysql.user、mysql.db 等权限表到内存缓存中；它仅在直接修改系统权限表后必需，GRANT/REVOKE 等语句无需执行。
FLUSH PRIVILEGES 到底在刷什么？
它不是“刷新用户”，也不是“重启权限系统”，而是**强制从磁盘重新加载 mysql.user、mysql.db 等权限表到内存缓存中**。MySQL 启动时会把权限表读进内存（比如全局权限存在 acl_users 数组里），后续所有鉴权都查内存副本——改磁盘不等于改内存，所以必须手动触发重载。
哪些操作后必须执行 FLUSH PRIVILEGES？
只有一种情况：你绕过 SQL 权限语句，直接用 INSERT/UPDATE/DELETE 修改了 mysql 库下的权限表（如 UPDATE mysql.user SET Select_priv='Y' WHERE User='test'）。这时 MySQL 完全不知情，内存里的权限位仍是旧值。
-
GRANT、REVOKE、CREATE USER、DROP USER—— 自动同步磁盘+内存，不需要FLUSH PRIVILEGES - 修改完
mysql.user后忘记FLUSH—— 新权限对新连接也不生效 - 用
mysqldump导入权限表或脚本批量更新系统表 —— 必须跟一句FLUSH PRIVILEGES
为什么执行了还是没生效？常见陷阱
即使 FLUSH PRIVILEGES 成功返回，你也可能发现权限“没变”——这不是命令失效，而是权限模型本身的限制：
- 已存在的连接不会重载权限：每个连接在登录瞬间就拷贝了一份权限快照，
FLUSH不影响它，必须让客户端断连重连 - 主机名匹配问题：权限是
'user'@'192.168.1.%'，但你用localhost连，实际匹配的是'user'@'localhost'这条记录（注意：本地 socket 连接默认走localhost，不是127.0.0.1） - 缺少
RELOAD权限：只有拥有该管理权限的用户才能执行FLUSH PRIVILEGES，普通账号执行会报错ERROR 1227 (42501): Access denied
生产环境要不要频繁用？
能不用就别用。虽然单次开销极小，但它是全局锁操作，会短暂阻塞其他权限相关请求（比如新连接认证）。更稳妥的做法是：
- 永远优先用
GRANT/REVOKE，而不是手改mysql表 - 批量初始化权限时，用
CREATE USER+GRANT脚本，而非INSERT INTO mysql.user - 如果真要刷，加个
SELECT USER(), CURRENT_USER();确认当前会话身份，避免刷错账户范围
最常被忽略的一点：FLUSH PRIVILEGES 解决不了“连接已建立但权限旧”的问题——它只管未来的新连接，老连接得自己断。
