MySQL 8.4 账号锁定怎么恢复：FAILED_LOGIN_ATTEMPTS、锁定状态与解锁验收

线上应用突然大量报错 ER_ACCOUNT_HAS_BEEN_LOCKED，通常不是“密码改错一次”这么简单：MySQL 8.4 会把连续错误密码、显式 ACCOUNT LOCK 和网络连不上区分开。先确认账号的锁定状态和策略，再决定临时解锁还是调整失败次数，才能避免解锁后马上再次被锁。

恢复顺序建议固定为：确认用户与来源主机 → 查看锁定状态和失败策略 → 判断是临时锁定还是管理员锁定 → 执行最小范围解锁 → 用真实连接和监控指标验收。

先把“账号被锁”与“密码不对”分开

MySQL 的登录失败可能来自密码错误、用户不存在、网络问题或账号已经锁定。只有账号确实被锁时，服务端才会返回 ER_ACCOUNT_HAS_BEEN_LOCKED，并增加 Locked_connects 计数。先保存一条失败连接的时间、用户名和来源主机，不要马上批量重置密码。

mysql -h db.example.internal -u report_reader -p

SHOW GLOBAL STATUS LIKE 'Locked_connects';
SHOW CREATE USER 'report_reader'@'10.20.%.%';

SHOW CREATE USER 会显示 ACCOUNT LOCK 或 ACCOUNT UNLOCK，也能看到账号级的失败登录策略。应用使用连接池时，报错日志中的来源主机尤其重要：同一个用户名在不同 Host 账户上可能是不同的授权对象。

MySQL 8.4 的临时锁定由两个参数共同决定

FAILED_LOGIN_ATTEMPTS N 表示连续错误密码达到多少次后触发锁定，PASSWORD_LOCK_TIME 表示锁定天数；前者或后者为 0，临时锁定就不会按这套策略生效。密码正确的登录会打断连续失败计数，但未知用户、网络不可达这类情况不应被当成密码失败。

CREATE USER 'report_reader'@'10.20.%.%'
  IDENTIFIED BY 'replace-with-a-secret'
  FAILED_LOGIN_ATTEMPTS 5
  PASSWORD_LOCK_TIME 1;

ALTER USER 'report_reader'@'10.20.%.%'
  FAILED_LOGIN_ATTEMPTS 5
  PASSWORD_LOCK_TIME 1;

示例中的密码只代表语法位置，生产环境不要把真实凭据写进工单、脚本或文章。若策略是 PASSWORD_LOCK_TIME UNBOUNDED，账号会保持锁定，直到管理员显式解锁；这和等待临时锁定自然到期不是同一件事。

先判断锁定来源，再选择解锁动作

如果 SHOW CREATE USER 显示显式锁定，说明有人或发布脚本执行过 ACCOUNT LOCK；如果显示未锁定但连接返回锁定错误，则要结合失败登录策略、错误日志和应用重试记录判断是否刚触发临时锁定。不要把“解锁”当成修复连接池的万能按钮，旧密码仍会继续制造失败尝试。

ALTER USER 'report_reader'@'10.20.%.%' ACCOUNT UNLOCK;
SHOW CREATE USER 'report_reader'@'10.20.%.%';

解锁前记录当前策略和业务负责人，解锁后立即让应用使用已经轮换的凭据，或暂时停掉持续重试的实例。权限不足时应让具备账号管理权限的管理员执行，不要直接修改 mysql.user 表。

把解锁结果验收到连接和指标

至少做一次与应用相同 Host 条件的真实连接测试，并核对应用侧连接池是否已经加载新凭据。随后查看锁定计数是否继续增长；如果数字还在增加，优先回到应用日志找旧配置、健康检查或定时任务，而不是反复执行 ACCOUNT UNLOCK。

SHOW GLOBAL STATUS LIKE 'Locked_connects';
SHOW CREATE USER 'report_reader'@'10.20.%.%';

-- 用应用相同的账号、Host 和 TLS 参数做一次最小查询
SELECT 1;

验收记录应该包含解锁前后的时间、账号与 Host、策略值、测试连接结果以及监控窗口。这样下一次发生相同故障时，能区分“账号又被锁”与“应用仍在使用旧密码”。

常见误区与安全边界

• 只写用户名不写 Host：可能解锁了错误的账户。
• 看到连接失败就调大失败次数：先排除连接池旧密码和错误配置。
• 直接改系统表：绕过正常 DDL，容易造成权限和审计记录不一致。
• 把网络故障算入失败次数：MySQL 的失败登录跟踪针对错误密码，不是所有连接失败。

相关问题

ACCOUNT UNLOCK 会重置密码吗？

不会。它只改变账号的锁定状态；密码是否正确、连接池是否已换密钥仍需单独验证。

为什么解锁后很快又被锁？

最常见原因是旧密码仍在某个实例、定时任务或健康检查中，持续触发连续失败。先按来源主机和时间查应用日志。

密码锁定策略应该设成多大？

按业务重试频率、人工响应时间和账号用途设定。生产账号应配合密钥轮换、告警和审计验证，不能只依赖一个较大的失败次数。

总结

MySQL 8.4 账号锁定排查的关键是把状态、策略和来源主机放在一起看。确认对象后用 ALTER USER ... ACCOUNT UNLOCK 做最小修复，再用真实连接、Locked_connects 和应用日志完成闭环，才能避免短暂恢复后再次中断。