max_connections设得过高会导致连接失败，因资源超限触发OOM Killer或MySQL主动拒绝；应依据Threads_connected峰值设为1.5–2倍，配合thread_cache_size（4–16）、ulimit和somaxconn协同调优。
max_connections 设定太高反而导致连接失败
MySQL 启动时会为每个连接分配独立线程和内存（如 sort_buffer、join_buffer），
超出物理资源承载能力后，新连接可能因
或
被拒绝——后者是 MySQL 主动拦截，前者是 OS 层面 OOM Killer 干预。
实操建议：
先查真实并发：用
观察峰值，而非按应用服务器连接池大小硬设
留余量但别堆高：线上建议设为峰值的 1.5–2 倍，超过 2000 需同步检查
和
配合连接池：应用端用 HikariCP 等时，
应 ≤
× 0.8，避免雪崩式重连
thread_cache_size 不是越大越好，多数场景 4–16 就够了
控制空闲线程缓存数量。当客户端断开，线程不立即销毁而是放入缓存；新连接到来时优先复用缓存线程，省去创建/销毁开销。但缓存过多线程会持续占用内存（每个线程约 256KB–1MB），且无实际收益。
判断是否需要调大：
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
看
—— 若该值每秒增长 > 1–2，说明缓存不足，频繁创建新线程
对比
：若长期稳定在
上限，说明当前值合理；若长期为 0 或极低，说明设高了也白搭
注意负载模式：短连接高频场景（如 PHP CGI）比长连接（Java 连接池）更依赖此参数
两个参数相互影响，必须一起看 Threads_created 和 Connections
单独调优
或
容易误判。关键要看这两个状态变量的组合关系：
高 +
持续上升 → 先加
，再确认是否真需扩
接近
但
很低 → 说明连接复用好，瓶颈不在线程创建，可能是慢查询或锁等待
波动剧烈（如 10→300→20）→ 检查应用是否未正确关闭连接，或连接池配置不当（如
过长）
Linux 内核限制常被忽略，导致参数失效
MySQL 的
受限于系统级资源，即使
配置文件
写了 5000，也可能起不来：
必须 ≥
+ 300（预留日志、复制等后台线程）
影响 TCP 连接队列长度，低于
时会出现连接超时（尤其突发流量）
systemd 服务启动时默认继承 shell 的 ulimit，需在
中显式加
改完记得
，否则内核限制没生效，MySQL 日志里也不会报错，只会默默降级运行。
max_connectionsCannot allocate memoryToo many connectionsSHOW STATUS LIKE 'Threads_connected';ulimit -n/proc/sys/net/core/somaxconnmaximumPoolSizemax_connectionsthread_cache_sizeSHOW STATUS LIKE 'Threads_created';Threads_cachedthread_cache_sizemax_connectionsthread_cache_sizeConnectionsThreads_createdthread_cache_sizemax_connectionsConnectionsmax_connectionsThreads_createdThreads_connectedidleTimeoutmax_connectionsulimit -nmax_connections/proc/sys/net/core/somaxconnmax_connections/etc/systemd/system/mysqld.serviceLimitNOFILE=65536systemctl daemon-reload && systemctl restart mysqld