max_connections设得过高会导致连接失败，因资源超限触发OOM Killer或MySQL主动拒绝；应依据Threads_connected峰值设为1.5–2倍，配合thread_cache_size（4–16）、ulimit和somaxconn协同调优。
max_connections 设定太高反而导致连接失败
MySQL 启动时会为每个连接分配独立线程和内存（如 sort_buffer、join_buffer），max_connections 超出物理资源承载能力后，新连接可能因 Cannot allocate memory 或 Too many connections 被拒绝——后者是 MySQL 主动拦截，前者是 OS 层面 OOM Killer 干预。
实操建议：
- 先查真实并发：用
SHOW STATUS LIKE 'Threads_connected';观察峰值，而非按应用服务器连接池大小硬设 - 留余量但别堆高：线上建议设为峰值的 1.5–2 倍，超过 2000 需同步检查
ulimit -n和/proc/sys/net/core/somaxconn - 配合连接池：应用端用 HikariCP 等时，
maximumPoolSize应 ≤max_connections× 0.8，避免雪崩式重连
thread_cache_size 不是越大越好，多数场景 4–16 就够了
thread_cache_size 控制空闲线程缓存数量。当客户端断开，线程不立即销毁而是放入缓存；新连接到来时优先复用缓存线程，省去创建/销毁开销。但缓存过多线程会持续占用内存（每个线程约 256KB–1MB），且无实际收益。
判断是否需要调大：
PHP与MySQL程序设计3
下载
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。 本书内容全面深入，适合各层次PHP和MySQL开发人员阅读，既是优秀的学习教程，也可用作参考手册。
- 看
SHOW STATUS LIKE 'Threads_created';—— 若该值每秒增长 > 1–2，说明缓存不足，频繁创建新线程 - 对比
Threads_cached：若长期稳定在thread_cache_size上限，说明当前值合理；若长期为 0 或极低，说明设高了也白搭 - 注意负载模式：短连接高频场景（如 PHP CGI）比长连接（Java 连接池）更依赖此参数
两个参数相互影响，必须一起看 Threads_created 和 Connections
单独调优 max_connections 或 thread_cache_size 容易误判。关键要看这两个状态变量的组合关系：
-
Connections高 +Threads_created持续上升 → 先加thread_cache_size，再确认是否真需扩max_connections -
Connections接近max_connections但Threads_created很低 → 说明连接复用好，瓶颈不在线程创建，可能是慢查询或锁等待 -
Threads_connected波动剧烈（如 10→300→20）→ 检查应用是否未正确关闭连接，或连接池配置不当（如idleTimeout过长）
Linux 内核限制常被忽略，导致参数失效
MySQL 的 max_connections 受限于系统级资源，即使配置文件写了 5000，也可能起不来：
-
ulimit -n必须 ≥max_connections+ 300（预留日志、复制等后台线程） -
/proc/sys/net/core/somaxconn影响 TCP 连接队列长度，低于max_connections时会出现连接超时（尤其突发流量） - systemd 服务启动时默认继承 shell 的 ulimit，需在
/etc/systemd/system/mysqld.service中显式加LimitNOFILE=65536
改完记得 systemctl daemon-reload && systemctl restart mysqld，否则内核限制没生效，MySQL 日志里也不会报错，只会默默降级运行。
