mysql 8.0+ 不支持 password_lock_time 的自动解锁功能，该参数仅作审计参考；真正可行的自动解锁需依赖事件调度器定时执行 alter user ... account unlock，或由应用层实现风控逻辑。
MySQL 8.0+ 中账号锁定后如何配置自动解锁时间
MySQL 8.0 引入了账户锁定功能（FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME），但要注意：默认不支持“自动解锁”——PASSWORD_LOCK_TIME 设为非零值时，账户被锁后必须由管理员手动执行 ALTER USER ... ACCOUNT UNLOCK 才能恢复。所谓“自动解锁”，实际只有两种可行路径：设为 0（即永不解锁，需人工干预），或设为 DEFAULT（表示使用全局默认值，而该默认值本身仍是 0）。
为什么 PASSWORD_LOCK_TIME = 1 不会 1 天后自动解锁？
这是最常被误解的点。PASSWORD_LOCK_TIME 的单位不是“天”，而是“天”，但它的生效前提是 MySQL 启用了基于时间的解锁机制——而 MySQL 官方实现中根本不检查账户锁定时间戳是否过期。也就是说，即使你设了 PASSWORD_LOCK_TIME = 1，MySQL 也不会在 24 小时后自动放开该账户；它只会在你显式执行解锁命令时才重置状态。这个参数的真实作用是：记录“本应锁定多久”，供审计或外部工具参考，而非触发自动行为。
替代方案：用事件调度器（Event Scheduler）模拟自动解锁
如果你确实需要接近“自动解锁”的效果，唯一可控的方式是借助 MySQL 自带的事件调度器定期扫描并解锁过期账户。前提是：
- 确保
event_scheduler已启用：SET GLOBAL event_scheduler = ON - 账户创建时明确记录锁定时间（例如用注释、额外元数据表，或依赖
mysql.user表中的password_last_changed字段间接推算） - 编写事件定期运行
ALTER USER ... ACCOUNT UNLOCK，例如：
CREATE EVENT unlock_expired_accounts ON SCHEDULE EVERY 1 HOUR DO ALTER USER 'baduser'@'%' ACCOUNT UNLOCK;
⚠️ 注意：ALTER USER 不能动态拼接用户名，所以必须为每个需自动管理的账户单独建事件，或用存储过程 + 预处理语句绕过（但会引入权限与安全风险）。
更现实的选择：用应用层或外部守护进程控制解锁逻辑
真正健壮的做法，是把“锁定-等待-解锁”流程移出 MySQL 内核：
- 登录失败时，应用记录失败时间到自己的审计表（如
login_attempts(user, ip, failed_at)） - 应用在下次认证前先查该表，判断是否仍在锁定窗口内（例如 15 分钟内超 5 次失败）
- MySQL 账户本身不启用
FAILED_LOGIN_ATTEMPTS，避免不可控的全锁死状态 - 这样既能实现灵活的冷却策略，又不会因 MySQL 重启、事件失效或权限变更导致逻辑断裂
MySQL 的账户锁定是粗粒度、运维向的功能，不适合替代应用级风控。一旦依赖它做自动行为，就会卡在“看起来配了，其实没反应”的坑里。
