FLUSH PRIVILEGES仅在直接修改mysql.user等权限表时必须执行，强制重载磁盘权限至内存缓存；使用ALTER USER或SET PASSWORD修改密码则自动生效，无需且无效于刷新。
MySQL 8.0 修改用户密码后，不会引发“缓存一致性问题”，FLUSH PRIVILEGES 也不是用来解决缓存一致性的操作——这是个常见误解。它只影响权限系统加载，和 Redis、查询缓存、InnoDB 缓冲池等完全无关。
你真正遇到的，很可能是：改完密码后应用连不上数据库，或报错 Access denied for user，然后下意识去查“缓存”“一致性”，结果绕进误区。
FLUSH PRIVILEGES 在 MySQL 8.0 中到底起什么作用？
它强制 MySQL 重新从
mysql.user等系统表加载权限数据到内存（即 privilege cache）；仅当你是手动 UPDATE/INSERT/DELETE 了
mysql库里的权限表（比如直接改mysql.user.authentication_string字段），才需要它；-
如果你用的是标准密码修改命令，比如：
ALTER USER 'root'@'localhost' IDENTIFIED BY 'newpass';
或SET PASSWORD FOR 'root'@'localhost' = 'newpass';
→ 那么 MySQL 会自动同步权限缓存，FLUSH PRIVILEGES**完全不需要，也不起作用**。 -
常见错误现象：
MySQL8 CRM Schema Design Expert下载面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 手动 UPDATE
mysql.user后没执行FLUSH PRIVILEGES→ 新密码不生效； - 执行了
FLUSH PRIVILEGES但密码还是不对 → 实际是账号 Host 不匹配（如用了'root'@'127.0.0.1'却连localhost），或密码加密方式不兼容（比如老客户端不支持caching_sha2_password）。
- 手动 UPDATE
MySQL 8.0 密码修改后连不上？优先排查这几点
-
检查账号 Host 是否精确匹配：
SELECT user, host FROM mysql.user WHERE user = 'your_user';
连接时用的 host（如localhost、127.0.0.1、%）必须和表中记录一致；localhost和127.0.0.1在 MySQL 中是两个不同账号。 -
确认认证插件是否被客户端支持：
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_user';
如果是caching_sha2_password，而你的客户端（如旧版 PHP mysqlnd、某些 Python 驱动）不支持，就会拒绝连接； 解决办法之一是降级插件（仅限内网可信环境）：ALTER USER 'your_user'@'host' IDENTIFIED WITH mysql_native_password BY 'password';
-
检查是否启用了密码过期策略：
SELECT user, host, password_expired FROM mysql.user;
若为Y，首次登录需重置密码，否则连接会被中断。 应用配置里是否还缓存着旧连接？比如连接池未关闭重连，或 DNS 缓存未刷新（尤其用了域名连数据库时）。
为什么有人误以为这是“缓存一致性”问题？
- 把 MySQL 内部的权限加载机制（privilege cache）当成“缓存层”；
- 把应用层连接池复用旧连接（仍持旧密码凭证）的现象，归因为“数据库缓存没更新”；
- 混淆了 MySQL 8.0 已彻底移除的
query_cache（和密码毫无关系）与权限加载逻辑。
真实情况是：没有跨系统缓存要“一致”，只有权限加载是否及时、客户端是否兼容、连接参数是否准确这三个硬性条件。
最常被忽略的一点：改完密码后，别急着 FLUSH PRIVILEGES，先看你是怎么改的——95% 的 case，根本不需要它；剩下 5%，要确认你改的是对的表、对的字段、对的 host，再 flush 才有意义。
