mysql原生不支持30分钟级账号锁定，因password_lock_time仅接受整数天单位，设小数会报错error 3671；锁定后需成功登录才解锁，无法自动到期解除，且仅对caching_sha2_password或mysql_native_password用户生效。
MySQL 原生不支持“锁定 30 分钟”这种分钟级配置——PASSWORD_LOCK_TIME 的单位固定为**天**，写 30 是锁 30 天，不是 30 分钟；写小数如 0.02083（30/1440）会报错 ERROR 3671 (HY000): Invalid value for PASSWORD_LOCK_TIME。真要实现接近“30 分钟”的效果，只能靠组合策略或应用层兜底。
为什么 PASSWORD_LOCK_TIME 不能设成分钟
MySQL 从 5.7.6 引入该参数，但设计上只接受非负整数，单位是「天」。官方文档明确说明：值为 0 表示永久锁定，>0 表示锁定多少个完整自然日（不是小时或分钟）。试图传入浮点数、字符串或毫秒值，都会被拒绝。
-
PASSWORD_LOCK_TIME 1→ 锁定 24 小时（精确到天，不考虑时分秒） -
PASSWORD_LOCK_TIME 0→ 永久锁定，必须由管理员执行ALTER USER 'u'@'%' ACCOUNT UNLOCK -
PASSWORD_LOCK_TIME 0.5或30（期望 30 分钟）→ 直接报错，语句失败
FAILED_LOGIN_ATTEMPTS 必须和 PASSWORD_LOCK_TIME 成对出现
单独设置 FAILED_LOGIN_ATTEMPTS 不会触发任何锁定行为。MySQL 会静默忽略该字段，mysql.user.account_locked 始终为 'N'，即使你查表看到 failed_login_attempts > 0 也说明还没达到阈值，而非已生效。
- 新建用户时必须写全：
CREATE USER 'u'@'%' IDENTIFIED BY 'p' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1 - 已有用户改策略必须重置认证插件：
ALTER USER 'u'@'%' IDENTIFIED WITH caching_sha2_password BY 'p' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1 - 若用户用的是
auth_socket（如默认root）或sha256_password，该策略完全不生效
connection_control 插件能模拟“延迟登录”，但不是真锁定
它不修改 account_locked 字段，也不拦截连接请求，只是让第 N+1 次失败登录的响应变慢。客户端收到的仍是 ERROR 1045 (28000)，无法区分是密码错还是被卡住。
- 必须同时加载两个插件：
CONNECTION_CONTROL和CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS -
connection_control_failed_connections_threshold = 5表示“从第 6 次失败开始加延迟”，但若connection_control_min_connection_delay = 0（默认），延迟就是 0 毫秒 → 完全无感 - 设 30 分钟延迟需写
connection_control_min_connection_delay = 1800000（单位毫秒），且该变量不能动态持久化，必须写进my.cnf并重启mysqld - 验证是否生效：运行
SHOW STATUS LIKE 'Connection_control_delayed_connections'，返回值非零才算真正起作用
真要实现 30 分钟自动解锁，只能靠应用层或 fail2ban
MySQL 原生机制里没有时间到期自动解锁的逻辑——PASSWORD_LOCK_TIME 到期后账号仍处于 account_locked = 'Y' 状态，直到有一次成功登录才重置计数并清除锁定标志。这意味着“锁 1 小时”实际可能持续数天，只要没人成功登录。
- 应用层方案：在登录接口里维护一个带 TTL 的失败记录（如 Redis 中
login_fail:u@h过期时间设为 1800 秒），每次登录前先检查是否被临时禁用 - fail2ban 方案：监听 MySQL 错误日志中的
Access denied for user记录，匹配同一 IP 高频失败后调用 iptables 或 firewalld 封禁该 IP 30 分钟 - 别碰
max_connect_errors：它封的是 IP，不是用户，NAT 环境下极易误伤，且错误提示是Host 'xxx' is blocked，和账号锁定无关
最容易被忽略的点是：所有原生锁定策略都依赖用户认证插件类型，而 root 默认用 auth_socket，所以对 root 设 FAILED_LOGIN_ATTEMPTS 基本无效；另外，validate_password 插件虽名义上只校验密码强度，但它是 FAILED_LOGIN_ATTEMPTS 生效的硬性前提——没启用它，策略就静默失效，还不报错。
