MySQL执行GRANT后，为何需FLUSH_操作以同步内存缓存与磁盘表数据？

本文共计914个文字，预计阅读时间需要4分钟。

plaintextGRANT 后面不需要 FLUSH PRIVILEGES——这是一个流传甚广的错误理解，执行它不仅没有用，还可能引发实际问题。

GRANT 语句本身就会同步内存与磁盘

MySQL 的 GRANT、REVOKE、CREATE USER 等权限管理语句，在内部实现上会同时完成两件事：写入磁盘的 mysql.user（或 mysql.db 等）表，以及更新内存中的权限结构（如 acl_users 数组）。这意味着权限变更在语句返回成功后就已生效，无需额外触发刷新。

常见误操作：

• 写了 GRANT SELECT ON mydb.* TO 'u'@'localhost'，又顺手加一行 FLUSH PRIVILEGES → 多余，且容易让你误以为“不加就不生效”
• 执行完 GRANT 仍连不上 → 实际可能是 host 不匹配（比如用了 'u'@'localhost' 却从 127.0.0.1 连），或没重连已有连接

FLUSH PRIVILEGES 只在直接改系统表时才必要

FLUSH PRIVILEGES 的唯一合法用途，是当你绕过 SQL 接口、直接用 UPDATE mysql.user 或 INSERT INTO mysql.db 修改权限表之后。此时 MySQL 完全不知情，内存缓存仍是旧快照，必须靠 FLUSH PRIVILEGES 强制全量重载磁盘数据。

但要注意：

• MySQL 8.0+ 中，mysql.user 的字段格式（如 authentication_string）、认证插件逻辑更严格，手动 UPDATE 极易出错，FLUSH PRIVILEGES 也无法修复校验失败
• 阿里云 RDS、腾讯云 CDB 等托管环境通常禁用 FLUSH PRIVILEGES，直接报错 ERROR 1227 (42501): Access denied
• account_locked 字段不能靠 UPDATE 设置，必须用 ALTER USER 'u'@'h' ACCOUNT LOCK，否则状态不同步

权限生效时机取决于作用域，不是“刷一下就全活”

即使你正确执行了 FLUSH PRIVILEGES 或 GRANT，权限也不是对所有连接“立刻全局生效”：

• 全局级权限（*.*）：仅对新连接生效；已有连接必须 QUIT 后重连才能获得
• 数据库级权限（db.*）：当前连接执行 USE db 后即生效
• 表级或列级权限：下次访问对应对象时立即检查，无需重连

所以看到 SHOW GRANTS FOR 'u'@'h' 返回了新权限，不代表当前连接能立刻执行 SELECT——得真跑一句语句验证，或确认连接是否已重建。

排查权限不生效，先确认是否跳过了权限校验

如果改了表、刷了缓存、重连了，还是连不上或报 Access denied，第一反应不应该是再试一遍 FLUSH，而是检查 MySQL 是否启动在 --skip-grant-tables 模式下。该模式下所有权限检查被跳过，GRANT 和 FLUSH 都无意义，连上去看到的权限状态也是假的。

真正容易被忽略的是：权限作用域中 host 的解析细节——客户端填 localhost 可能走 socket，填 127.0.0.1 却走 TCP，对应的是 'u'@'localhost' 和 'u'@'127.0.0.1' 两个完全不同的账户。