立刻恢复连接需执行FLUSH HOSTS清空host缓存或重置错误计数；若无RELOAD权限，可临时调整max_connect_errors触发重置；但需排查应用密码错误、连接池未关闭、防火墙中断等根本原因。
MySQL 报错 Host is blocked because of many connection errors 怎么立刻恢复连接
这是 MySQL 服务端主动拒绝连接的保护机制，不是网络或密码问题。只要触发了 max_connect_errors 限制（默认 100），对应 IP 就会被加入阻塞列表，后续所有连接（无论账号密码对错）都会直接报这个错。
立刻恢复的办法只有两个：清空 host 缓存 或 重置该 host 的错误计数，不能靠等、不能靠重启客户端。
- 执行
FLUSH HOSTS是最常用方式，但需有RELOAD权限；普通应用账号通常没有，得找 DBA 或用高权限账号操作 - 如果无法执行
FLUSH HOSTS（比如权限受限），可临时改小max_connect_errors值再设回原值，强制触发内部重置（不推荐长期用） - 注意：
FLUSH HOSTS会清掉所有被 block 的 host，也包括其他误连失败的 IP，属于“杀鸡取卵”式操作
为什么 FLUSH HOSTS 有时没用
常见误解是“执行完就万事大吉”，其实它只解决表层阻塞，不碰根本原因。下面几种情况会让问题反复出现：
- 应用配置里用户名/密码写错，每次启动都试连失败 → 错误计数持续累加
- 连接池未正确关闭连接，短时间高频建连又断开（尤其在测试环境），被 MySQL 当作异常行为统计
- 防火墙或代理中途断开 TCP 连接，MySQL 收不到 FIN 包，认为连接异常中断，计入错误次数
-
max_connect_errors设得太低（比如调成 10），而业务本身就有偶发 DNS 解析慢、网络抖动等情况
max_connect_errors 和 connect_timeout 的关系别搞混
这两个参数常被一起调整，但作用完全不同，混用反而埋坑：
-
max_connect_errors是“连续失败次数阈值”，控制 host 是否被 block，单位是次数，影响的是host_cache表 -
connect_timeout是“单次握手等待秒数”，超时后报Lost connection to MySQL server at 'handshake'，不计入错误计数 - 调大
connect_timeout对解决 host block 毫无帮助；反过来，只调大max_connect_errors而不修底层连接逻辑，只是把爆雷时间延后 - 生产环境建议保持
max_connect_errors≥ 200，同时配合监控抓出真实错误源头（比如慢 DNS、错配的 SSL 参数）
怎么查哪个 IP 被 block 了，以及当前错误计数
MySQL 8.0+ 把这些信息放进了 performance_schema，老版本只能靠日志或猜。别靠 SHOW VARIABLES LIKE 'max_connect_errors' —— 它只告诉你阈值，不告诉你谁超了。
- 查当前被 block 的 host：
SELECT * FROM performance_schema.host_cache WHERE HOST IS NOT NULL AND FIRST_SEEN - 看指定 IP 的错误计数：
SELECT HOST, SUM_CONNECT_ERRORS FROM performance_schema.host_cache WHERE HOST = '192.168.1.100'; - 错误日志里搜
Host 'xxx' is blocked可定位首次触发时间，结合应用日志比对更准 - 注意：
performance_schema.host_cache默认可能关闭，需确认performance_schema开启且host_cache_size足够（默认 256）
真正卡住人的，从来不是怎么 flush，而是不知道哪次连接失败被算进去了——比如一个健康检查脚本用错端口，每天连 5 次，20 天就刚好触顶。这种安静的错误，比报错还难揪。
