backlog仅控制全连接队列长度，即三次握手完成但未被accept()取走的连接数；其实际值取min(backlog, net.core.somaxconn)，需同步调整应用配置与系统参数，且不解决连接泄漏或认证瓶颈问题。
back_log不是用来“扛高并发”的，它只管那一小段握手完成但还没被accept()的连接
很多人一看到“高并发连不上”，第一反应就是把back_log从50改成2000。这反而暴露了一个根本误解：back_log不处理SYN包（那是tcp_max_syn_backlog的事），也不管连接建好后干啥（那是max_connections和wait_timeout的事）。它只管TCP三次握手完成、内核已把连接放进全连接队列（ACCEPT queue）、但MySQL主线程还没调accept()捞走的那一小段“等待区”。
所以它溢出的典型现象是：客户端报Connection refused或超时，MySQL错误日志里却查不到对应记录；SHOW PROCESSLIST里大量unauthenticated user状态堆积；Aborted_connects持续上涨，但Threads_connected远低于max_connections。
改了back_log但没生效？先看系统级限制net.core.somaxconn
back_log的实际生效值，永远取你配置值和系统参数net.core.somaxconn的较小者。设成1024没用，如果net.core.somaxconn = 128，MySQL启动时会静默截断，并在error log里写warning——但很多人根本没去看log。
必须同步调整：
- 临时生效：
sudo sysctl -w net.core.somaxconn=1024 - 持久化：
echo "net.core.somaxconn = 1024" >> /etc/sysctl.conf && sudo sysctl -p - MySQL配置中设
back_log = 1024（建议≤net.core.somaxconn值） - 重启
mysqld（运行时SET GLOBAL back_log = ...不生效）
验证是否真生效：ss -lnt | grep :3306，看Recv-Q列能否撑到接近你设的值。
back_log和max_connections完全不是一回事，别混着调
这是最常踩的坑。前者是TCP层“排队通道”，后者是MySQL层“工作席位”。
-
back_log溢出 → 客户端根本连不上，报系统级错误，MySQL日志里没记录 -
max_connections溢出 → 客户端能完成握手，但立刻收到ERROR 1040: Too many connections
一个健康配置示例：若max_connections = 1000，back_log设256～512足够；设到2000就过度了，反而掩盖真实连接泄漏问题。真正该优先排查的是长期Sleep的连接：SELECT ID, USER, HOST, TIME FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 300;
back_log调太大反而会掩盖连接泄漏和短连接滥用问题
很多团队把back_log一路拉到2000甚至5000，结果客户端“暂时能连上”了，但Aborted_connects还在涨，unauthenticated user越来越多——这不是参数不够，是业务侧在疯狂建短连接、认证失败、或连接池没配好。
更危险的是，它会掩盖真正的瓶颈：比如应用没复用连接、密码错/账号不存在导致线程卡在认证阶段、DNS解析慢拖长accept耗时等。这些都不是加大back_log能解决的。
真正要做的，是结合slow_query_log、performance_schema里的连接建立路径分析，以及应用层连接池（如HikariCP）的maxLifetime、connectionTimeout配置来收口。否则，再大的back_log也只是给漏水的桶多加一层盖子。
