结论是MySQL密钥轮换不能只改数据库密码，必须同步更新所有服务端凭据引用，并设计双凭据并行期；ALTER USER后新连接立即拒绝旧密码，但已有连接持续运行，需重启应用或刷新连接池才能生效。
直接说结论：MySQL连接密钥（即用户名/密码）轮换，不能只改数据库里的密码，必须同步更新所有服务端的凭据引用，且需设计双凭据并行期来避免连接中断。
ALTER USER 后连接立刻断开？这是预期行为
执行 ALTER USER 'app_user'@'%' IDENTIFIED BY 'new_pass' 后，所有持旧密码的活跃连接会继续运行，但新连接请求将被拒绝。这意味着正在运行的应用如果没重启或没刷新连接池，会在下次建连时失败——不是“改完就断”，而是“下次建连就断”。
- 连接池（如 HikariCP、Druid）通常不会自动重试新密码，需显式触发 reload 或重启应用
- 长连接（如 MySQL Router、ProxySQL 转发的连接）不受影响，直到连接被主动关闭或超时
- 如果应用使用
mysql_native_password插件，而新密码含特殊字符（如@、/），URL 编码不正确会导致解析失败
为什么推荐新建用户而非复用旧用户名轮换
复用原用户名（如 app_user）改密，等于把所有服务的“单点故障风险”绑在一起；一旦某处漏改或改错，整个服务链就卡住。新建用户（如 app_user_v2）本质是做一次可控的“凭证灰度发布”。
- 数据库权限可完全复制：
SHOW GRANTS FOR 'app_user'@'%';→ 手动执行相同GRANT语句到新用户 - 旧用户保留至少 72 小时，确保所有服务完成切换并验证日志中无
Access denied for user 'app_user' - Kubernetes 中滚动更新时，新 Pod 用新凭据启动，老 Pod 自然淘汰，无需强制 kill
Secret 管理工具里 base64 编码不是加密，只是编码
username: YXBwX3VzZXI= 这类 base64 值在 Kubernetes Secret 或环境变量里随处可见，但它不提供任何安全防护——只要能读取 Secret 对象，就能 decode 出明文。真正起作用的是 Secret 的访问控制策略（RBAC）、命名空间隔离和审计日志。
- 别把 base64 当密码保护手段；它只是绕过 YAML 中非法字符的兼容性层
- 若用 HashiCorp Vault，优先走
vault kv get secret/db动态拉取，而非把凭据固化进镜像或 ConfigMap - 云厂商 KMS（如 AWS Secrets Manager、腾讯云 SSM）支持自动轮换 + Lambda 触发更新，但需确认应用代码调用的是最新版本 API
轮换窗口内最易忽略的三个盲区
90% 的轮换失败不是出在 SQL 或配置上，而是卡在这些角落：
- 定时任务（CronJob、Airflow DAG）往往独立维护凭据，容易遗漏，建议统一注入
DB_CREDENTIALS_VERSION环境变量驱动加载逻辑 - 开发/测试环境的 .env 文件或 IDE 数据库连接配置，常被当成“临时”忽略，实则可能连着生产库（尤其当 host 是内网 IP）
- 备份脚本（mysqldump、xtrabackup）硬编码了密码参数，
--password=old_pass这种写法在轮换后直接导致备份失败
