MySQL 9.4 为什么把 back_log 默认值提到 10000：连接突发时先看这条边界

线上服务在发布、定时任务或流量回补时，可能在很短时间内同时发起大量 TCP 连接。MySQL 9.4 把 back_log 的默认值提高到 10000，解决的是这段“连接刚到、主线程还没来得及接收”的排队空间，而不是把数据库的并发能力直接扩大十倍。真正要判断是否安全，必须把 MySQL 参数和操作系统的监听队列放在一起看。

back_log 先解决的是瞬时连接堆积

back_log 可以理解为 MySQL 监听入口前的一段短队列。主 MySQL 线程需要一点时间检查连接并启动处理线程；如果请求在这段间隔里集中到达，队列可以先把它们堆住。队列满了，服务器会暂时停止回应新的连接请求。

这和“服务器已经建立了多少连接”是两件事。max_connections 是并发连接容量，连接建立后还会受到线程、内存、连接池和业务事务的影响。把 back_log 调大，不能解决连接已经建立但业务线程耗尽的问题，也不能替代应用侧的连接池限流。

MySQL 9.4 的 10000 与 max_connections 不是一回事

MySQL 9.4.0 的发布说明明确写着：back_log 默认值提高到 10000。服务器变量文档同时给出了 0 到 65535 的范围，并说明它是全局、非动态变量。这里最容易误读的是：10000 是监听队列的默认上限，不是推荐把 max_connections 也改成 10000。

还有一个边界值得记住：如果显式把 back_log 设为 0 或 -1，MySQL 会使用 max_connections。因此升级后看到 10000，先确认配置文件里有没有显式值，再判断它是不是默认值。

把操作系统监听上限一起对齐

back_log 不能高于操作系统对监听队列的限制。MySQL 文档给出的 Linux 核对项包括：

sysctl net.core.netdev_max_backlog
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.core.somaxconn

它们分别落在不同的网络处理环节，不能只改其中一项就宣布完成。需要提高目标值时，先在变更单里记录 back_log、max_connections 和三项 sysctl 的现值；如果最小的系统上限仍小于 MySQL 值，实际监听能力就会被更小的边界卡住。

生产环境不建议为了追求一个漂亮的 10000 直接改内核参数。先确认问题确实是连接突发，再结合文件描述符、连接池上限和入口层重试策略做小范围变更，并保留原值作为回滚点。

用配置与状态检查确认边界

可以先用下面的 SQL 把两个 MySQL 变量放在同一张检查单里：

SHOW VARIABLES WHERE Variable_name IN ('back_log', 'max_connections');

随后查看启动配置中是否出现 back_log=0、back_log=-1 或明确的固定值，再在 Linux 主机读取三项 sysctl。注意，back_log 是启动期变量，不能把一次运行时修改当成永久生效；需要调整时，应修改受管控的配置文件并按维护窗口重启，再重复上述检查。

判断顺序可以很简单：第一，看是否真的存在短时连接洪峰；第二，看 max_connections 和应用连接池是否已经逼近容量；第三，取 MySQL 目标值与三项系统上限的最小值。只有三层边界都能解释问题，才值得调整 back_log。

常见问题

back_log 越大，MySQL 就能承受越多并发吗？

不能。它只增加短时间内尚未完成接收的排队空间，并不增加已经建立的并发连接容量。

升级到 MySQL 9.4 后必须手动设置 back_log=10000 吗？

不必先手动设置。先确认版本、配置文件和实际变量值；如果系统上限或业务连接模型不匹配，盲目固定 10000 反而会掩盖真正的连接池问题。

为什么改了 back_log，连接突发仍然失败？

常见原因是 Linux 监听队列上限更小，或者失败发生在并发连接耗尽、文件描述符、入口层重试等其他边界。要把三类证据放在同一时间窗口内对照。