max_connections设过高会因每个连接占用thread_stack、sort_buffer_size等会话缓冲区，叠加导致内存超限触发OOM Killer；需结合物理内存、实际峰值连接数及系统ulimit综合配置。
单纯调高 max_connections 不仅不能防内存溢出，反而大概率会触发 OOM Killer 杀掉 mysqld 进程。 它只是把连接耗尽的报错往后拖，而每个新连接都在吃内存——你看到 “Too many connections”，背后可能是几百个 Sleep 连接 + 每个连带 3–5MB 缓冲区，直接压垮 8GB 机器。
为什么 max_connections 设太高会内存溢出
MySQL 每个连接不是只占一个 socket 句柄，它会为每个连接分配：thread_stack（默认 256KB）、sort_buffer_size、join_buffer_size、read_buffer_size 等会话级缓冲区。这些值乘上 max_connections 就是潜在峰值内存开销。
- 例如：8GB 服务器设
max_connections = 1000，若sort_buffer_size = 4M，光这一项就可能吃掉 4GB 内存（1000 × 4MB） -
innodb_buffer_pool_size是另一大头，建议 ≤ 物理内存 70%，且必须预留 ≥2GB 给系统和其他进程 - 总内存估算公式（近似）：
innodb_buffer_pool_size + ((sort_buffer_size + join_buffer_size + read_buffer_size) * max_connections)，别超物理内存 80% - Linux 层面还有
ulimit -n限制，若系统最大文件描述符数（Max open files）小于max_connections + 50，MySQL 会静默降级或启动失败
如何安全地设置 max_connections 值
不是拍脑袋定 500 或 1000，而是按真实负载和内存余量推算：
- 先查历史峰值：
SHOW STATUS LIKE 'Threads_connected';+ Prometheus 监控过去 7 天最高值 - 预留 20% 余量，但硬上限建议取
min(500, 峰值 × 1.2)；小业务 100–200 足够 - 8GB 内存机器，保守配
max_connections = 300，同时把sort_buffer_size从默认 2MB 改成512K（避免单连接吃太狠） - 改完必须验证：
SELECT @@max_connections;（不是SHOW STATUS LIKE 'Max_used_connections'）
改了 max_connections 还是 OOM？检查这三处
很多团队调完参数发现照样被杀，问题不在 max_connections 本身，而在它放行了更多“低效连接”：
-
wait_timeout还是默认 28800（8 小时）？Web 应用应设为300（5 分钟），否则 Sleep 连接堆积不释放 - 应用层没 close() 或连接池配置错：比如 HikariCP 的
maximumPoolSize> MySQL 的max_connections，多个实例一叠加就爆 - 系统级限制没同步：systemd 下必须在
/usr/lib/systemd/system/mysqld.service里加LimitNOFILE=10000，否则配置再大也打不开那么多 fd
真正卡住人的从来不是“该设多少”，而是 wait_timeout 和应用层 close() 是否落地、系统 ulimit 是否跟上、以及有没有人定期看 SHOW PROCESSLIST 里 Time > 300 的 Sleep 行——这些细节漏掉一个，调参就白干。
