grant、revoke、create user、drop user及多数alter user语句在mysql 5.7.6+中自动同步磁盘与内存权限缓存，无需flush privileges；仅直接dml修改mysql系统表（如update mysql.user）才必须执行该命令以强制重载。
执行 FLUSH PRIVILEGES 不需要，是因为你没绕过 MySQL 的权限管理接口——绝大多数标准操作根本不会触发“缓存未同步”问题。
哪些语句自带权限刷新，根本不用 FLUSH PRIVILEGES
MySQL 从 5.7.6 起，GRANT、REVOKE、CREATE USER、DROP USER 和绝大多数 ALTER USER 操作都会自动更新内存 ACL 缓存，无需额外命令。
-
GRANT SELECT ON db.* TO 'u'@'%'：磁盘写入 + 内存重建一步完成，返回成功即生效（新连接立刻可用） -
ALTER USER 'u'@'localhost' IDENTIFIED BY 'pwd'：8.0.16+ 中已修复所有边缘延迟，不需刷 -
CREATE USER 'u'@'192.168.1.%' IDENTIFIED BY 'x'：用户元数据和权限结构同步初始化
加 FLUSH PRIVILEGES 不报错，但属于冗余操作；更危险的是，它可能掩盖真实失败——比如 ALTER USER 因用户不存在而报错，你却因 FLUSH PRIVILEGES 成功返回误判为“改密成功”。
为什么直接 UPDATE mysql.user 后必须刷
因为 UPDATE mysql.user SET authentication_string = ... 这类 DML 只改磁盘，完全不触达 MySQL 权限子系统的内部刷新逻辑。内存里仍用着启动时加载的旧 acl_users 数组，新密码/新 host /新插件字段全被忽略。
- 典型高危场景：
mysqldump导入权限表、脚本批量修正Host字段、手动 INSERT 新账号 - 8.0+ 中风险更高：手填
authentication_string容易格式错误（缺 salt、长度不对、plugin 不匹配），FLUSH PRIVILEGES会把坏数据直接载入内存，导致账号永久不可用 - 托管环境（如阿里云 RDS）通常禁用该命令，直接报
ERROR 1227 (42501): Access denied
执行了 FLUSH PRIVILEGES 还不生效？先查这三件事
它不是万能开关，只是强制重载信号。很多“不生效”跟缓存无关，而是更基础的匹配或连接问题。
- 当前连接权限已固化：哪怕刚授了
ALL PRIVILEGES，也得QUIT后重连才感知变更 -
'u'@'localhost'和'u'@'127.0.0.1'是两个独立账号，改了前者，用后者登录当然无效 - 认证插件不兼容：MySQL 8.0 默认用
caching_sha2_password，老版客户端（如旧 Navicat、MySQLdb）可能静默降级失败，报错类似Plugin caching_sha2_password could not be loaded
真正容易被忽略的，是你改的那行记录是否真被匹配到了——用 SELECT user, host, plugin FROM mysql.user WHERE user = 'xxx'; 查完，再在目标连接里执行 SELECT CURRENT_USER();，确认实际绑定的是哪一行。
