因为mysql认证只发生在连接建立时，已建立的连接复用原有上下文，不重新校验密码；密码变更后旧连接仍有效，新连接才需验证新凭据。
为什么修改密码后连接池里的连接还能用
因为连接池中已建立的连接是“活连接”，只要 TCP 链路没断、MySQL 服务端没主动踢掉、连接本身没超时，它就继续有效——密码变更不影响已建立的连接认证状态。MySQL 的认证只发生在连接建立时，后续所有查询都复用该连接上下文，不重新校验密码。
典型表现是：改完密码后，应用照常读写，但新连接（比如重启服务、连接池扩容、空闲连接被回收后重建）会失败，报错 Access denied for user 或 Plugin caching_sha2_password could not be loaded。
这不是 bug，是 TCP 连接生命周期与权限系统解耦的正常行为。关键点在于：连接池不会监听数据库用户表变更，也没法主动感知密码更新。
HikariCP / Druid 怎么让旧连接失效并触发重连
不能“强制重连”单个连接，但可以让连接池在下次使用前自动剔除/重建——靠的是健康检查 + 连接回收机制。重点不是改密码那一刻，而是后续连接怎么被验证和替换。
-
validationQuery必须设为SELECT 1（或兼容 MySQL 8.0+ 的SELECT 1），否则连接池跳过有效性检测 -
connection-test-query（Druid）或connection-test-query（HikariCP）要启用，且确保语句能执行（比如避免用SHOW TABLES这类需额外权限的） -
maxLifetime要小于 MySQL 的wait_timeout（例如设为 1800000ms = 30min，而服务器端wait_timeout=3600），否则连接会在池里“自然死亡”前一直挂着 -
idleTimeout控制空闲连接存活时间，设太长会导致旧连接卡在池里很久不释放
一旦配置生效，下次从池里 getConnection() 时，连接池会先执行 validationQuery；若失败（比如因密码变更导致权限不足），该连接被标记为无效并销毁，再新建一个——这就是你看到的“自动切换到新密码连接”的过程。
Java 应用里捕获密码变更导致的连接失败并重试
即使连接池做了健康检查，首次获取连接仍可能拿到一个刚被 MySQL 主动关闭（如 wait_timeout 触发）但还没被池检测到的“僵尸连接”。这时业务代码需要兜底。
典型错误码包括：2006 (MySQL server has gone away)、1045 (Access denied)、1251 (caching_sha2_password plugin)。不要笼统 catch SQLException，应判断 getSQLState() 或 getErrorCode()：
- 遇到
1045，大概率是密码/用户/host 不匹配，需检查配置是否同步更新 - 遇到
2006或2013，说明连接已断，可立即重试一次（幂等操作） - 避免无脑重试：对非幂等写操作（如 INSERT），重试前必须确认上一次是否已执行成功（查日志或幂等键）
示例逻辑片段：
try {
return dao.query(...);
} catch (SQLException e) {
if (e.getSQLState().equals("28000") || e.getErrorCode() == 1045) {
log.error("DB auth failed, check password config");
throw e; // 不重试，配置问题需人工介入
} else if (e.getErrorCode() == 2006 || e.getErrorCode() == 2013) {
return dao.query(...); // 简单重试一次
}
throw e;
}
真正“立刻生效”的办法只有重启或清空连接池
如果生产环境急需让所有连接立即使用新密码（比如旧密码已泄露），最可靠的方式不是等连接自然过期，而是主动干预：
- HikariCP：调用
HikariDataSource.close()再重建数据源（需配合 Spring 的@RefreshScope或手动刷新 Bean） - Druid：调用
DruidDataSource.close()，或通过监控页面点击“清空连接池”按钮（暴露了/druid/index.html的前提下） - Spring Boot：发 POST 到
/actuator/refresh（需开启 endpoint）+ 修改配置中心里的密码，触发 DataSource 自动重建（依赖spring-cloud-starter-bootstrap）
注意：close() 是阻塞操作，期间所有 DB 请求会失败，务必选在低峰期操作。另外，某些老版本 Druid 的 removeAbandonedOnBorrow 可能干扰判断，建议统一升级到 1.2.23+ 并禁用该参数。
最易被忽略的一点：改完密码后，别忘了检查 mysql.user 表里的 plugin 字段。MySQL 8.0 默认用 caching_sha2_password，而很多连接池驱动（尤其旧版 mysql-connector-java 5.x）不支持，会静默 fallback 到连接失败——这时候光改密码没用，还得 ALTER USER ... IDENTIFIED WITH mysql_native_password。
