只有直接修改系统权限表时才必须执行FLUSH PRIVILEGES，它强制重载磁盘权限到内存缓存，不刷新则新权限不生效；GRANT/REVOKE操作在MySQL≥8.0.16中无需刷新。
什么时候必须执行 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;
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 版本，再决定要不要刷、怎么刷、刷完怎么验。
