grant后无需执行flush privileges，因其本身已同步更新磁盘与内存权限；该命令仅在直接修改mysql系统表时必需，且8.0+中手动改表风险高、托管环境常禁用。
GRANT 后根本不需要 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' 两个完全不同的账户。
