什么时候必须执行 FLUSH PRIVILEGES
只有在**绕过 GRANT/REVOKE 语句、直接修改系统权限表**时，才「必须」执行
FLUSH PRIVILEGES。比如你用
UPDATE mysql.user改了密码，或手动
INSERT INTO mysql.db加了库级权限——MySQL 不会自动感知这些变更，内存里的权限缓存仍沿用旧数据，不刷新就永远不生效。 ✅ 必须刷新的场景：
UPDATE mysql.user SET authentication_string = PASSWORD('xxx') WHERE User='u1'; 后不执行 FLUSH PRIVILEGES→ 新密码无效 ❌ 不需要刷新的常见操作（MySQL ≥8.0.16）：
GRANT SELECT ON db.* TO 'u1'@'%';→ 权限立即生效，无需额外命令 ⚠️ 版本陷阱：MySQL 8.0.15 及更早版本中，即使只用
GRANT，也建议加
FLUSH PRIVILEGES，否则可能遇到权限延迟或不一致
FLUSH PRIVILEGES
到底做了什么
它不是“更新权限”，而是「强制重载」：清空内存中已缓存的全部权限数据（包括
mysql.user、
mysql.db、
mysql.tables_priv等 6 张核心表），再从磁盘完整读一遍，重建缓存。整个过程是原子性的全量覆盖，没有增量合并逻辑。 不执行该命令 → 内存缓存 ≠ 磁盘真实权限状态 → 用户连不上、授权查不到、
SHOW GRANTS显示旧结果 执行后可立刻验证：
FLUSH PRIVILEGES;<br>SHOW GRANTS FOR 'u1'@'%';注意：它不影响当前已建立的连接的权限（已登录用户的会话权限不变），只影响后续新连接或新权限检查请求
为什么不用重启 MySQL？
重启确实也能让权限生效，但代价太大：所有连接断开、事务中断、查询失败、主从同步可能延迟。而
FLUSH PRIVILEGES是轻量热操作，毫秒级完成，适合生产环境紧急修复。 但它不是万能的：如果权限表本身被误删、字段类型错乱、或
mysql库损坏，
FLUSH会失败并报错（如
ERROR 1036: Table 'user' is read only） 高并发下频繁执行无益：每刷一次就要全表读取 + 内存重建，对负载敏感；日常运维应优先用
GRANT/REVOKE，避免手动改表 复制环境中要注意：主库刷了，从库权限表不会自动同步 —— 如果从库也做了本地权限修改，得各自刷新
容易被忽略的关键细节
最常踩的坑不是“忘刷新”，而是“刷了却没效果”，原因往往藏在细节里：
用户 Host 匹配问题：'u1'@'localhost'和
'u1'@'127.0.0.1'是两个不同用户，改错 Host 就白刷 权限作用域层级未匹配：给
'u1'@'%'授了
SELECT在
db1.*，但程序连的是
db2→ 刷也没用 MySQL 8.0+ 密码认证插件变更：
authentication_string字段内容格式变了，用老版
PASSWORD()函数更新会导致认证失败，此时刷了也登不进
FLUSH PRIVILEGES不解决网络层拦截：防火墙、skip-networking、bind-address 限制等，和权限刷新完全无关
MySQL 权限生效本质是「磁盘定义 → 内存缓存 → 连接时校验」三步链路，
FLUSH PRIVILEGES只管中间那一步。真要排查权限异常，先确认改的是哪个表、哪个用户、哪个 host、哪个 MySQL 版本，再决定要不要刷、怎么刷、刷完怎么验。
