背景

最近做了一次 MySQL 8.0 的小版本升级，升级完重启之后业务侧开始报连接异常，日志里出现了一些奇怪的 warning。表面看不致命，但实际有部分客户端被 MySQL 直接拉黑了连不上。最后 DBA 排查出来是 max_connect_errors 这个参数默认值太小导致的，改大之后问题消失。

记录一下整个过程，避免下次再踩。

现象

升级重启之后，错误日志里陆续出现这类 warning：

[2026-04-30 05:25:49 #20157.0]  WARNING del (ERRNO 800): failed to delete events[656], it has already been removed
[2026-04-30 05:38:49 $24029.0]  WARNING kill_event_workers(:595): waitpid(24423) failed, Error: No child processes[10]
[2026-04-30 05:38:55 @26321.0]  WARNING set_max_connection: max_connection is exceed the maximum value, it's reset to 1024

业务侧的表现是：部分应用服务器开始报 Host 'xxx.xxx.xxx.xxx' is blocked because of many connection errors，必须执行 FLUSH HOSTS 才能恢复，但过一会儿又会被拉黑。

排查思路

最开始怀疑是 max_connections 不够，但实际看了一下连接数远没到上限。后来注意到关键报错信息 blocked because of many connection errors，这是 MySQL 主机黑名单机制的典型提示，方向就明确了——是 max_connect_errors 这个参数在作怪。

根因：max_connect_errors 默认值 100

MySQL 对每一个客户端 IP（host）都会维护一个错误计数器，存放在 performance_schema.host_cache 里。当某个 host 的连接错误累积超过 max_connect_errors 时，MySQL 会直接把这个 host 拉黑，拒绝所有后续连接，直到计数器被清零或者重启 MySQL。

而 max_connect_errors 的默认值是 100，在生产环境这是一个非常容易触发的值：

• 升级重启瞬间，大量客户端同时发起重连
• 网络抖动、TCP 三次握手失败、鉴权重试等都会累积错误次数
• 一台应用服务器只要瞬间出现 100 次失败，这台 host 就被永久封禁

升级期间几乎一定会触发。

解决方案

把参数改大就行，业内常见的做法是改成 10 万甚至 100 万：

# my.cnf
[mysqld]
max_connect_errors = 100000

也可以在线动态修改，不需要重启：

SET GLOBAL max_connect_errors = 100000;

改完之后告警立刻消失，业务恢复正常。

配套命令

排查和恢复过程中常用的几条命令记录一下。

查看当前值：

SHOW VARIABLES LIKE 'max_connect_errors';

查看 host_cache，看哪些 IP 累积了错误：

SELECT * FROM performance_schema.host_cache
WHERE sum_connect_errors > 0;

手动清空黑名单（被拉黑的 host 立即恢复）：

FLUSH HOSTS;
-- MySQL 8.0.23 之后官方推荐改用：
TRUNCATE TABLE performance_schema.host_cache;

几个容易混淆的参数

排查过程中很容易把下面几个参数搞混，顺手对比一下：

这次踩的坑是第二个，但日志里 set_max_connection ... reset to 1024 这条 warning 一开始很容易把人误导到第一个上去。

经验总结

1. max_connect_errors 默认值 100 在生产环境基本等同于地雷，新部署 MySQL 时务必改大，建议至少 10 万起步。
2. 任何 MySQL 重启动作前，先确认这个参数已经调过，否则瞬时重连风暴大概率会触发拉黑。
3. 看到 Host 'xxx' is blocked because of many connection errors 不要只想着 FLUSH HOSTS 救火，要去改根因参数。
4. 监控里加上 performance_schema.host_cache 的巡检，能提前发现哪些客户端在异常重连。

参考

• MySQL 8.0 Reference Manual: max_connect_errors
• MySQL 8.0 Reference Manual: The Host Cache