MySQL连接数超限时客户端报“Too many connections”错误，但若连接未达服务端则可能因back_log溢出或系统限制导致超时、Connection refused；max_connections需结合内存合理设置，避免OOM。
连接数超限时 MySQL 报什么错
客户端连不上时最常见的是 Too many connections 错误，说明已达到 max_connections 上限。但注意：这个错误只在连接成功进入 MySQL 服务端后才抛出；如果连接请求甚至没被内核收进来，你可能看到的是超时、Connection refused 或应用层直接报“无法建立连接”，这时候问题往往出在更底层——比如 back_log 队列溢出或系统级连接限制。
max_connections 不是越大越好
它控制 MySQL 内部允许并发活跃连接的最大数量，但每个连接会占用内存（线程栈、缓存等），设得过高容易触发 OOM。实际值要结合服务器内存和平均连接内存开销估算：
-
max_connections默认值通常为 151，生产环境常见设为 500–2000，不建议盲目调到 5000+ - 每连接基础内存消耗约 256KB–1MB（取决于是否启用查询缓存、排序缓冲区大小等），可用
SHOW VARIABLES LIKE 'thread_stack'和SHOW VARIABLES LIKE 'sort_buffer_size'辅助估算 - 修改后需重启或用
SET GLOBAL max_connections = N（临时生效，重启丢失）
back_log 是 TCP 连接队列，不是 MySQL 连接池
back_log 控制的是 Linux 内核中，MySQL 所监听 socket 的**未完成三次握手连接队列长度**（SYN queue），不是 MySQL 自己管理的连接数。当并发建连请求猛增（如秒杀、健康检查风暴），而 MySQL 处理 accept() 的速度跟不上，队列满就会丢弃新 SYN 包，表现为客户端连接超时或失败。
- 默认值通常为 50 或 80，远低于高并发场景需求
- 它受系统参数
net.core.somaxconn限制，若back_log设为 1024，但net.core.somaxconn = 128，MySQL 启动时会自动截断并警告 - 必须同时调大系统级参数：
sysctl -w net.core.somaxconn=2048，并写入/etc/sysctl.conf - MySQL 8.0+ 中该值上限还受
tcp_max_syn_backlog影响，但多数现代内核下主要看somaxconn
光调参数还不够：得看连接是不是真在用
很多连接数问题其实源于应用没正确释放连接（如忘记 close()、连接池配置不合理、长事务阻塞）。先确认真实压力来源：
- 查当前连接：
SHOW PROCESSLIST，重点关注Command列为Sleep且Time很大的连接——可能是连接池泄漏或应用未回收 - 检查连接池配置：例如 HikariCP 的
maximumPoolSize应 ≤ MySQL 的max_connections，否则多个服务实例叠加就容易打爆 - 短连接高频场景（如 PHP-FPM 模式）比长连接更依赖
back_log和系统somaxconn，因为每次请求都新建 TCP 连接
真正卡住的地方，往往不在 MySQL 配置里，而在连接从内核队列被 accept() 出来之后的那几百毫秒——应用怎么用、什么时候关、有没有复用，比单纯调大两个数字重要得多。
