服务器配置如何调整 MySQL 最大连接数限制

必须同步调整MySQL配置、systemd限制和资源水位，否则易失效或重启回退；应先分析Max_used_connections、Threads_connected及慢查询，避免盲目调高导致内存耗尽或性能下降。

调高 MySQL 最大连接数不能只改一个地方，必须同步处理 MySQL 配置、系统级限制和资源水位，否则大概率不生效或重启后回退。

先看真实压力，别急着调

登录 MySQL 执行两条命令：

1. SHOW VARIABLES LIKE 'max_connections'; —— 看当前设的上限
2. SHOW GLOBAL STATUS LIKE 'Max_used_connections'; —— 看历史上真正用过的最高并发数

如果 Max_used_connections 长期在 max_connections 的 80% 以上，说明确实快撑不住；如果常年只有 20–50，盲目调高只会浪费内存、加剧线程竞争。

再顺手查一下：SHOW STATUS LIKE 'Threads_connected'; 实时看现在连了多少个，结合慢查询日志判断是不是有长事务或未释放连接把池子堵死了。

永久修改要配三处

只改 my.cnf 是不够的，MySQL 启动时会受操作系统限制“截断”你的设置：

1. 在 /etc/my.cnf 或 /etc/mysql/my.cnf 的 [mysqld] 段下加：

   max_connections = 1000

2. 检查 systemd 服务限制：编辑 /usr/lib/systemd/system/mysqld.service（或 mariadb.service），在 [Service] 下加：

   LimitNOFILE=10000

   LimitNPROC=10000

3. 执行重载与重启：

   systemctl --system daemon-reload

   systemctl restart mysqld

改完立刻验证：SHOW VARIABLES LIKE 'max_connections'; 必须返回你设的值，否则就是某处被系统卡住了。

临时救火可以 SET GLOBAL，但有硬约束

线上突然爆满时可用：

1. SET GLOBAL max_connections = 1000; —— 立刻生效，不用重启
2. 但它受三个限制：

   • 不能超 MySQL 编译上限（默认 100000）

   • 不能超 ulimit -n 设置（常见默认 1024）

   • MySQL 进程重启后自动还原

所以它只是应急手段，不能替代配置文件修改。

调高之后必须盯住资源和行为

每个连接至少占用 1–2MB 内存（尤其开了 sort_buffer、join_buffer 时），连接数翻倍，内存可能翻倍还多。更隐蔽的是性能拐点：

1. CPU 上下文切换开销明显上升
2. 锁竞争加剧，QPS 反而下降
3. Threads_running（活跃线程）持续高于 50，说明真正在干活的连接已饱和

建议配合监控：用 SHOW PROCESSLIST 查连接来源和 SQL，开慢查询日志定位堵点，应用端务必启用连接池（如 HikariCP），并合理设置 maximumPoolSize 和 idle timeout。