MySQL改密码不中断已有连接是设计行为：认证仅发生在连接建立时，而非每次SQL执行；连接池复用旧连接，数据库不会主动踢出已认证连接，新建或回收后重建连接才校验新密码。
MySQL改密码不中断已有连接是设计行为
这不是 bug，是 MySQL 的正常机制：认证只发生在连接建立时，而不是每次执行 SQL 时。只要连接没断、没超时、没被池回收，它就一直用原来的认证上下文跑着，跟服务端密码是否变更完全无关。
常见表现就是你刚 ALTER USER 完，Java 应用页面照常刷新、查询照常返回——不是密码没改成功，而是连接池里的连接根本没重新握手。
- 连接池（如 HikariCP、Druid）启动时建好一批连接，后续复用它们
- MySQL 不会主动踢掉已认证成功的连接，哪怕对应用户的密码已被覆盖
- 只有新建连接或旧连接因空闲超时被销毁后重建时，才会触发新密码校验
怎么验证“连接确实还在用旧凭据”
最直接的方式是手动断开并重连：在应用服务器上执行一次全新连接测试，绕过连接池缓存。
- 运行
mysql -u 用户名 -h 数据库地址 -P 端口 -p，输入新密码看能否登录 - 如果能登进去，说明密码已生效；登不进，再查
SELECT user, host, plugin FROM mysql.user WHERE user = '用户名'; - 检查
plugin字段是不是caching_sha2_password，旧驱动可能不认
为什么 Navicat / Workbench 连不上，但 Java 应用却正常
GUI 工具通常每次点击“连接”都新建 TCP 连接，而 Java 应用靠连接池复用旧连接——所以工具报错 Authentication plugin 'caching_sha2_password' cannot be loaded，应用却毫无感知。
- Workbench 7.x、Navicat 12.0.24 之前版本不支持
caching_sha2_password - Java 应用若用的是 JDBC 5.x 或未加
allowPublicKeyRetrieval=true，新建连接也会失败，只是你还没触发新建动作 - 别信配置文件里写了密码就万事大吉，得确认实际建连时用的是哪个用户@host组合
真正容易被忽略的三个点
生产环境最容易栽在这几个地方：
- 改的是
'root'@'localhost'，但应用连的是'root'@'%'，压根不是同一个账户 - 密码改了，但应用配置里还挂着旧密码，等连接池自然淘汰完老连接才暴露问题——可能拖一两天
- 用了双密码机制（
RETAIN CURRENT PASSWORD），旧密码仍有效，你以为切过去了，其实只是“暂时共存”
