不能只靠应用重启轮换数据库密码，因会中断活跃连接导致事务失败，且MySQL/PostgreSQL默认不主动终止旧凭据会话；须先在数据库侧更新凭证，再强制应用重建连接池。
为什么不能只靠应用重启来轮换数据库密码
应用重启触发新凭证加载，看似简单，但会中断连接池中的活跃连接，导致事务失败或超时错误。更关键的是，MySQL 和 PostgreSQL 默认不主动踢掉旧凭据建立的会话——旧密码仍能建新连接，直到显式失效或服务重启。轮换后若没同步清理旧凭据残留，等于白换。
实操建议：
- 轮换前先在数据库侧执行
ALTER USER ... IDENTIFIED BY（MySQL）或ALTER ROLE ... PASSWORD（PostgreSQL），确保服务端已更新 - 避免依赖“下次启动生效”，必须让应用层主动重建连接池，而非等连接自然超时
- 检查应用是否启用连接验证（如
testOnBorrow或validationQuery），否则旧连接可能持续存活数小时
Spring Boot 应用如何安全热更新 DataSource 凭证
Spring Boot 2.3+ 支持运行时刷新 DataSource，但默认不启用凭证热替换。直接改 application.properties 中的 spring.datasource.password 并调用 /actuator/refresh，只会更新配置对象，不会重建 HikariCP 连接池。
实操建议：
- 使用
@RefreshScope注解修饰自定义DataSourceBean，并在配置变更后触发HikariDataSource.close()+ 重建 - 更稳妥的做法是监听
EnvironmentChangeEvent，捕获spring.datasource.username或password变更，然后调用hikariDataSource.evictAllConnections() - 注意：HikariCP 的
setPassword()是线程安全但不生效的“假方法”，必须重建整个数据源实例
轮换窗口期如何避免双密钥冲突与权限错配
生产环境常采用“双密钥过渡”策略：先加新用户、授同权，再删旧用户。但 GRANT 权限复制容易遗漏 WITH GRANT OPTION 或 REPLICATION SLAVE 等特殊权限，导致应用报 Access denied for user。
实操建议：
- 用
SHOW CREATE USER 'old_user'@'%'导出原始建用户语句，手动比对并复现到新用户 - 禁止直接
CREATE USER new_user@'%' IDENTIFIED BY 'xxx'后GRANT ALL——ALL PRIVILEGES不包含GRANT OPTION，也不包含管理类权限（如SUPER） - 轮换脚本中加入校验步骤：用新凭据连库执行
SELECT CURRENT_USER(), USER()，确认身份和权限上下文一致
凭证轮换后如何快速验证连接池是否真正切换
光看应用日志里 “reinitialized datasource” 不够，得确认连接池中所有连接都用了新凭据。常见误判是看到连接重建日志，却忽略连接池最小空闲数（minimumIdle）仍维持着旧连接。
实操建议：
- 查 HikariCP 内部状态：
hikariDataSource.getHikariPoolMXBean().getTotalConnections()和getActiveConnections()，配合netstat -anp | grep :3306观察客户端 IP 和连接时间戳 - 在数据库侧执行
SELECT user, host, command, time FROM information_schema.PROCESSLIST WHERE user LIKE '%your_app%'，确认所有连接显示的是新用户名 - 临时开启
log_connections = on（PostgreSQL）或general_log = ON（MySQL），抓取认证阶段原始用户标识，绕过中间件混淆
最易被忽略的一点：某些云数据库代理（如阿里云 RDS Proxy、AWS RDS Proxy）会缓存认证结果，轮换后需单独刷新代理配置，否则它仍用旧 token 转发请求。
