MySQL账号被封主因是触发max_connect_errors阈值（默认100次失败连接），导致自动锁死而非人为禁用；可通过SHOW VARIABLES、SELECT account_locked及错误日志排查，并需FLUSH HOSTS或RESET CONNECTION手动解锁。
MySQL账号被封是因为触发了max_connect_errors
不是所有“账号被封”都是人为禁用，绝大多数是 MySQL 自动锁死：当同一个客户端 IP 连续失败（比如密码错、用户不存在）达到 max_connect_errors 次，默认 100 次，对应账号就会被标记为“访问被拒绝”，错误信息是 Access denied for user 'xxx'@'yyy' (using password: YES)，但实际密码可能完全正确——因为账号已被临时封禁。
怎么查当前设置和谁被锁了
先确认是否真被锁，再看阈值和来源 IP：
- 查当前限制：
SHOW VARIABLES LIKE 'max_connect_errors'; - 查哪些账号被锁（需有
PROCESS权限）：SELECT host, user, password_last_changed FROM mysql.user WHERE account_locked = 'Y';（注意：MySQL 5.7+ 才有account_locked字段；老版本只能靠日志或观察连接行为推断） - 查最近失败连接（依赖
log_warnings = 2且开启 general_log 或 error log）：grep "Access denied" /var/log/mysql/error.log | tail -20
SQL注入本身不会直接触发max_connect_errors，但会放大风险
很多人误以为“防SQL注入=防账号锁”，其实二者逻辑不同：SQL 注入攻击目标是数据，而 max_connect_errors 是针对 TCP 连接层的暴力试探防御。但问题在于——如果应用层没做输入校验，攻击者可构造大量带错误凭证的请求（比如 ' OR 1=1 -- 碰撞登录接口），这些请求仍会走 MySQL 认证流程，每次失败都计数。所以真正要堵的是「无效认证请求的源头」：
- Web 层加登录失败次数限制（如 5 分钟内最多 5 次失败），别把压力全甩给 MySQL
- 禁止前端暴露原始 MySQL 错误（比如把
Access denied直接返回给用户），统一返回模糊提示 - 确保应用连接池复用连接，避免短连接高频重连（每个新连接都算一次尝试）
- 若用 PHP 的
mysqli_connect()，不要在循环里反复调用它去试密码
自动解锁不能靠 MySQL 自身，得靠外部机制
MySQL 没有内置“X 分钟后自动解封”功能。所谓“自动解锁”，本质是定期清理被锁账号或重置计数器：
- 重置单个主机的错误计数：
FLUSH HOSTS;（影响全局，慎用；仅对当前实例有效，重启后恢复） - 只清指定账号的错误记录（MySQL 8.0.22+）：
RESET CONNECTION FOR 'user'@'host';（需 SUPER 权限） - 更稳妥的做法：写个脚本定时查
performance_schema.host_cache表，找出错误数超限的 host 并FLUSH HOSTS，或结合 fail2ban 把恶意 IP 从系统防火墙封掉 - 注意：
max_connect_errors是全局变量，动态修改需SET GLOBAL max_connect_errors = 200;，但不建议盲目调高，应配合监控告警而非掩盖问题
最常被忽略的一点：很多 DBA 改了 max_connect_errors 却忘了它只对新连接生效，已锁账号不会自动恢复——必须手动 FLUSH HOSTS 或等 MySQL 重启（如果配置了 skip-host-cache 则该机制本身就不工作）。
