flush privileges仅强制重载磁盘权限表至内存，不校验字段合法性、host匹配或插件兼容性；它不影响已存在连接，新权限需重连才生效，且grant/revoke等标准语句已自动刷新缓存，无需手动执行。
FLUSH PRIVILEGES 本身不修复权限逻辑错误
执行 FLUSH PRIVILEGES 后权限“没生效”，大概率不是命令失败，而是你改的那条权限本身就有问题。它只做一件事：把磁盘上 mysql.user、mysql.db 等表的内容全量重载进内存——但不会校验字段值是否合法、host 是否匹配、plugin 是否兼容。
-
SELECT_priv字段写成'YES'或'1'都无效，必须是'Y' -
Host值多一个空格（如'user'@'localhost '）就查不到对应行 - MySQL 8.0+ 中
authentication_string格式不对（比如用OLD_PASSWORD()写入），FLUSH PRIVILEGES会静默加载失败，但不报错 - 账号被
ALTER USER 'u'@'h' ACCOUNT LOCK锁定，但你只改了account_locked='Y'字段——这种 DML 操作不触发状态同步，FLUSH PRIVILEGES也无法修复
已有连接不会自动更新权限快照
MySQL 在连接建立时就把该用户的权限快照固化在会话里。FLUSH PRIVILEGES 只影响新连接，对已存在的连接完全无感。你看到“改了还是连不上”，往往只是忘了断开重连。
- 当前连接执行
SHOW GRANTS FOR CURRENT_USER;，显示的永远是登录那一刻的权限，不是磁盘最新状态 - 验证是否真生效，必须新开一个客户端连接：
mysql -u u -p -h 127.0.0.1（注意localhost和127.0.0.1是两个不同账号） - Docker 或远程环境容易连错实例：你以为在刷宿主机 MySQL，实际执行的是容器内未启动的服务
GRANT 后加 FLUSH PRIVILEGES 是冗余操作
从 MySQL 5.7 开始，所有标准授权语句（GRANT、REVOKE、ALTER USER）都会自动刷新内存缓存。加 FLUSH PRIVILEGES 不报错，但纯属浪费时间，还可能掩盖真正的问题。
-
GRANT SELECT ON db.* TO 'u'@'%';执行成功后，新连接立刻可用 - 如果加了
FLUSH PRIVILEGES才“看起来生效”，说明你没重连，或Host匹配失败（比如授的是'u'@'localhost'，却用127.0.0.1连） - 托管服务（阿里云 RDS、腾讯云 CDB）通常直接禁用
FLUSH PRIVILEGES，报ERROR 1227 (42501)，此时硬刷毫无意义
MySQL 8.0+ 手动改表 + FLUSH 已不可靠
8.0 版本起，权限表结构和认证机制变化很大：password_expired、account_locked、plugin 字段耦合紧密，手动 UPDATE mysql.user 极易出错，FLUSH PRIVILEGES 也救不回来。
- 明文密码字段
Password已废弃，必须用authentication_string+ 正确插件格式（如caching_sha2_password） - 直接
UPDATE可能漏掉mysql.global_grants或mysql.role_edges表，导致部分权限缺失 - 某些字段（如
max_questions）类型变更，填数字字符串会转成 0，FLUSH后仍是无效值
真正需要 FLUSH PRIVILEGES 的场景只剩一种：你绕过所有 SQL 接口，用脚本批量导入 mysql 库的 SQL 文件，或者用 mysqldump 恢复旧权限表之后——其他时候，优先用 GRANT，然后重连。
