MySQL 8.0+双密码机制是唯一支持不停机平滑轮换的原生方案，通过RETAIN CURRENT PASSWORD分三阶段实施：先加新密保留旧密、验证双密可用、再DROP OLD PASSWORD清理旧密，全程无需重启。
MySQL 8.0+ 的双密码机制（RETAIN CURRENT PASSWORD）是唯一能真正实现应用不停机、密码平滑轮换的原生方案。其他方式——比如直接 ALTER USER 或脚本定时替换配置——都会导致部分连接瞬间中断或认证失败。
为什么不能直接 ALTER USER 换密码？
直接执行 ALTER USER 'app_user'@'%' IDENTIFIED BY 'new_pass' 后，所有使用旧密码的活跃连接会被立即拒绝（MySQL 8.0 默认行为），新连接又必须立刻切换新密码。现实中应用重启、连接池刷新、多实例同步都存在时间差，极易引发“500 错误潮”或主从延迟加剧。
- 连接池（如 HikariCP、Druid）不会自动感知密码变更，需重启或手动清空连接
- 微服务集群中各节点更新顺序不可控，旧密码连接可能持续数分钟
- MySQL 8.0.14+ 才支持双密码；5.7 及更早版本无安全轮换能力，只能接受停机窗口
MySQL 8.0+ 双密码轮换实操步骤
核心是分三阶段：先加新密码保留旧密码 → 等待所有旧连接自然退出/滚动更新 → 再清除旧密码。全程无需重启服务或应用。
- 第一阶段（启用双密码）：
ALTER USER 'app_user'@'%' IDENTIFIED BY 'new_pass' RETAIN CURRENT PASSWORD; - 第二阶段（验证双密码生效）：用旧密码和新密码分别连接测试，确认两者均可成功：
mysql -u app_user -p'old_pass' -e "SELECT 1"和mysql -u app_user -p'new_pass' -e "SELECT 1" - 第三阶段（清理旧密码）：等业务侧完成配置更新、连接池重建后，执行
ALTER USER 'app_user'@'%' DROP OLD PASSWORD;
注意：DROP OLD PASSWORD 不会踢掉仍在用旧密码的连接，只禁止后续新连接使用旧密码——这是关键安全边界。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
自动化轮换必须绕开的坑
很多团队写 Python 脚本调用 mysql-connector-python 自动执行 ALTER USER，但忽略了两个硬约束：
- 执行双密码操作的用户必须拥有
SYSTEM_USER权限（非GRANT OPTION），普通 DBA 账号默认没有，需显式授权：GRANT SYSTEM_USER ON *.* TO 'rotator'@'%'; - MySQL 8.0.32+ 引入了
password_history和password_reuse_interval策略，若新密码与历史密码重复或未满足间隔天数，ALTER USER会静默失败（错误信息为ER_PASSWORD_CANNOT_BE_REUSED），脚本必须捕获并重试 - 不要在应用配置里硬编码密码；轮换时应通过配置中心（如 Consul、Nacos）下发新密码，并触发应用热重载连接池
轮换后必须验证的三个点
光执行 SQL 不代表轮换成功。生产环境必须检查：
- 确认
mysql.user表中该用户的password_last_changed字段已更新，且password_lifetime未被意外设为 0 - 查
SHOW PROCESSLIST，观察是否仍有大量app_user的连接来自旧 IP 或旧客户端版本（说明部分实例未更新） - 检查 MySQL 错误日志，过滤
Access denied for user—— 若轮换后仍持续出现，说明有漏网的旧配置或 DNS 缓存未刷新
双密码不是“设完就完”，它把密码变更从秒级原子操作，变成了需要监控、等待和收口的运维过程。最容易被忽略的是第三阶段的 DROP OLD PASSWORD —— 不做这步，等于永远留着一个过期但可用的后门。
