back_log控制TCP未完成三次握手的SYN队列长度，仅缓解瞬时建连丢包，不能提升并发处理能力；它与max_connections无关，调大需先设net.core.somaxconn再配back_log并重启MySQL。
back_log 不是并发连接数上限，调它解决不了“Too many connections”，只管“连都连不上”的瞬间丢包。
为什么改了 back_log 客户端还是 Connection refused
常见现象是健康检查或微服务启动时批量建连失败，错误日志里看不到 Too many connections，而是直接超时或报 Connection refused。这说明请求压根没进 MySQL，被 Linux 内核 TCP 队列丢弃了——back_log 控制的就是这个队列长度（SYN queue），不是 MySQL 自己的连接池。
-
back_log默认只有 50～80，秒级 100+ 新建连接就会溢出 - MySQL 启动时会把
back_log值和系统参数net.core.somaxconn对比，取小值；设成 2048 但net.core.somaxconn = 128，实际生效仍是 128，error log 里会有 warning - 即使队列变长，若 MySQL 处理
accept()过慢（比如线程卡在慢查询、CPU 过载），新连接照样被丢
怎么安全调大 back_log（必须两步一起走）
单独改 MySQL 配置毫无意义，必须先调操作系统限制，再设 MySQL 参数，顺序不能反：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 查当前系统上限：
sysctl net.core.somaxconn；若 ≤ 512，建议调到2048或65535（生产环境慎用过高值，避免 SYN 队列过长引发重传） - 临时生效：
sudo sysctl -w net.core.somaxconn=2048；持久化写入/etc/sysctl.conf并执行sysctl -p - MySQL 配置中设
back_log = 2048（建议 ≤net.core.somaxconn，通常设为相同值） - 重启 mysqld（该参数只读，
SET GLOBAL无效） - 验证：
ss -lnt | grep :3306看Recv-Q是否能撑到接近你设的值
back_log 和 max_connections 到底什么关系
两者完全独立，但常被混为一谈：
-
back_log是 TCP 层“等待区”：存的是刚发来 SYN、还没完成三次握手的连接请求 -
max_connections是 MySQL 层“工作区”：存的是已完成握手、已认证、正在执行或休眠的连接 - 如果
back_log溢出，客户端连不上，错误不在 MySQL 日志里；如果max_connections溢出，客户端能握手成功，但立刻收到Too many connections - 一个合理配比：设
max_connections = 1000，back_log设256～512足够；设到 2000 就过度了，反而可能掩盖真实连接泄漏问题
真正要盯住的，是那些没释放的 Sleep 连接——它们不占 back_log，但会吃光 max_connections，还拖慢 accept() 速度。调参只是表象，连接复用、及时 close、合理设置 wait_timeout 才是根因。
