必须用ALTER USER ... IDENTIFIED BY ... RETAIN CURRENT PASSWORD实现双密码切换,因SET PASSWORD仅覆盖主密码且无条件清空辅助密码,导致旧密码立即失效;其不参与双密码机制、不校验插件、不检查空密码,易引发ERROR 1045等连接中断问题。

必须用 ALTER USER ... IDENTIFIED BY ... RETAIN CURRENT PASSWORD,其他方式要么报错,要么清空旧密码导致连接中断。
为什么 SET PASSWORD 不能用于双密码切换
SET PASSWORD 完全不参与双密码机制。它只覆盖主密码,且无条件清空辅助密码——哪怕你前一秒刚用 RETAIN CURRENT PASSWORD 设好双密码,下一条 SET PASSWORD 就会让旧密码立即失效。
- 执行
SET PASSWORD FOR 'u'@'h' = 'new'后,旧密码登录直接报ERROR 1045 (28000) - 混用
SET PASSWORD和ALTER USER的脚本,会导致部分节点双密码生效、部分失效,排查困难 -
SET PASSWORD不检查当前密码是否为空,也不校验认证插件,失败时往往无明确提示,容易误判成功
执行 ALTER USER RETAIN CURRENT PASSWORD 前必须确认三件事
漏检任意一项,都会触发 ERROR 3031(空密码)或 ERROR 3894(插件不匹配)。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理(CRM)系统设计、评审、优化或生成数据库模式时,应使用此项技能。
- 账户当前密码非空:查
SELECT user, host, authentication_string FROM mysql.user WHERE user = 'u' AND host = 'h',确保authentication_string非NULL且非空字符串 - 认证插件必须是
caching_sha2_password:运行SELECT plugin FROM mysql.user WHERE user = 'u' AND host = 'h',不匹配需先执行ALTER USER 'u'@'h' IDENTIFIED WITH caching_sha2_password BY 'xxx' - MySQL 版本 ≥ 8.0.14:运行
SHOW VARIABLES LIKE 'version'确认,低于该版本语法不存在
主从环境下的执行顺序和验证要点
在复制架构中,双密码切换不是主库一执行就完事。从库没同步完成前切应用,会有一批连接因“从库还不认新密码”而失败。
- 主库执行
ALTER USER 'u'@'h' IDENTIFIED BY 'new' RETAIN CURRENT PASSWORD后,立刻查SHOW SLAVE STATUS\G,等所有从库Seconds_Behind_Master = 0再推进应用端切换 - 不要在事务中包裹该语句 ——
ALTER USER是隐式提交,事务控制无效,反而误导人以为能回滚 - 验证是否真双活:分别用新密码和旧密码连一次,都应成功;注意
mysql.user表中authentication_string字段值不变(仍是旧密码哈希),说明辅助密码已保留
DISCARD OLD PASSWORD 必须显式调用才能清理
双密码不会自动过期,也不会随改密次数增加而自动清理。只要没执行 DISCARD OLD PASSWORD,最早那次被 RETAIN CURRENT PASSWORD 保留下来的密码就一直有效——哪怕你已经改了七次密码。
-
DISCARD OLD PASSWORD不接受参数,也不支持批量操作,每个账户都得单独执行 - 安全审计时发现半年前的密码仍能登录,大概率就是漏掉了这一步
- 误执行一次不带
RETAIN CURRENT PASSWORD的ALTER USER 'u'@'h' IDENTIFIED BY 'x',会导致主密码变成x,但辅助密码仍是最初那个,等于凭空多留一个长期有效口令
最容易被忽略的是:双密码状态完全依赖 mysql.user 表里的元数据标记,而不是密码哈希本身。这意味着你查 authentication_string 看不到“两个密码”,只能靠行为验证——新旧密码都能连上,才是真生效。

















