调高max_connections不能提升并发能力，它仅控制允许连接数而非处理能力；需检查真实连接水位、释放sleep连接、同步调整系统文件描述符限制、缩短wait_timeout和interactive_timeout、优化应用层连接池配置。

max_connections 调高不等于并发能力提升，单纯改这个值常治标不治本——它只是“允许连进来”的门禁卡数量，不是“能高效处理多少请求”的能力。

---

查清当前连接真实水位，别只看 max_connections

很多线上服务报 Too many connections，但 SHOW VARIABLES LIKE 'max_connections' 显示设到了 2000，实际活跃连接却只有 30。问题不在上限，而在连接没释放。

• 用 SHOW STATUS LIKE 'Threads_connected' 看当前已连数
• 用 SHOW PROCESSLIST 扫描大量 Sleep 状态连接（尤其是 time > 300 的）
• 按用户统计： SELECT user, COUNT(*) FROM information_schema.PROCESSLIST GROUP BY user，确认是否某应用或中间件在泄漏连接

永久修改 max_connections 必须同步调系统级限制

Linux 默认文件描述符限制（ulimit -n）通常为 1024，而 MySQL 每个连接至少占用 1 个 fd。即使配置里写了 max_connections = 3000，实际生效值会被卡在系统限制之下。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 检查当前限制：cat /proc/$(pgrep mysqld)/limits | grep "Max open files"
• 修改 systemd 服务配置（如 /etc/systemd/system/mysqld.service.d/override.conf）：

  [Service]
  LimitNOFILE=65536

• 重启 systemd 配置：systemctl daemon-reload && systemctl restart mysql

wait_timeout 和 interactive_timeout 比 max_connections 更影响连接复用

MySQL 默认这两个超时是 28800 秒（8 小时），意味着空闲连接会挂 8 小时才断开。连接池若没配 maxLifetime 或 idleTimeout，就会持续占用 max_connections 名额。

• 线上建议设为 300–600 秒：SET GLOBAL wait_timeout = 300; SET GLOBAL interactive_timeout = 300;
• 该设置需写入配置文件才能持久化，否则重启后还原
• 注意：PHP 的 mysql_pconnect、Java 的 HikariCP/Druid 都依赖这些超时做连接清理，不调它们，光调 max_connections 是白忙

连接池配置不当，比数据库本身更易引发连接耗尽

应用层连接池才是连接生命周期的实际控制者。数据库端调高上限，只是给错误配置兜底，不是正解。

• 检查连接池最大连接数（如 HikariCP 的 maximumPoolSize）是否远高于业务实际 QPS 所需
• 确认 connection-timeout（获取连接超时）和 idle-timeout（空闲回收）是否合理，避免连接长期滞留
• 监控指标重点看：连接池的 active vs idle 比例、等待获取连接的线程数 —— 这些比 Threads_connected 更早暴露瓶颈

真正卡住并发的，往往不是数据库允许连多少人，而是连接建了不关、池子满了不放、超时设得太长还假装健康。调参前先跑一遍 SHOW PROCESSLIST 和应用连接池日志，比直接改 max_connections 有用十倍。