必须执行flush privileges仅当直接修改mysql系统表（如update mysql.user）时；使用grant、alter user等标准语句则自动生效，无需且不建议手动刷新。
不需要重启数据库，执行 FLUSH PRIVILEGES 就够了。 MySQL 的权限检查完全基于内存中加载的快照，服务启动时读一次权限表，后续所有鉴权都走内存副本。改完权限后只要重载内存即可，重启是过度操作，且会导致连接中断和服务抖动。
什么时候必须手动执行 FLUSH PRIVILEGES
只在你绕过 MySQL 权限管理接口、直接修改系统表时才需要——这是关键判断点。
- 用
UPDATE mysql.user、INSERT INTO mysql.db或DELETE FROM mysql.tables_priv等 DML 手动改表 → 必须FLUSH PRIVILEGES - 用
GRANT、REVOKE、ALTER USER、CREATE USER等语句修改 → 自动生效，无需 手动刷新 - 改的是
max_connections这类全局变量 → 和权限无关，属于配置项，需SET GLOBAL或改配置文件 + 重启
FLUSH PRIVILEGES 执行失败的常见原因
命令本身简单，但失败往往暴露权限或环境问题，不是语法错。
- 执行用户没有
RELOAD权限 → 报错ERROR 1227 (42000): Access denied; you need (at least one of) the RELOAD privilege(s) - 在只读从库上执行 → 报错
ERROR 1290 (HY000): The MySQL server is running with the --read-only option - 权限表字符集异常（比如
mysql.user是utf8mb4，但客户端连接用latin1）→ 可能导致部分字段解析失败，FLUSH后权限加载不全
权限改了但新连接还是报 Access denied？检查这几点
不是 FLUSH 没用，而是权限变更没落到正确的记录上，或连接复用掩盖了问题。
- 确认
User和Host组合完全匹配：比如你改的是'app'@'10.20.30.%'，但应用连的是'app'@'10.20.30.45'，而该行在表里不存在 -
authentication_string字段值是否符合当前认证插件要求：MySQL 8.0+ 默认用caching_sha2_password，填明文密码或旧格式哈希会失效 - 已有连接不会重载权限：
FLUSH PRIVILEGES只影响新连接；应用若用连接池（如 HikariCP），得等空闲连接超时或主动KILL会话 - 别漏掉关联权限表：只改
mysql.user不够，库级权限在mysql.db，表级在mysql.tables_priv，手改时容易遗漏
最稳妥的做法是：永远优先用 GRANT/REVOKE，避免手改系统表；如果真要手改，改完立刻 FLUSH PRIVILEGES，并验证新连接行为——别依赖旧连接反馈。
