怎样调整数据库的并发连接数？

本文目录导读：

1. 重要前提：调整前需要评估
2. 调整 MySQL 并发连接数
3. 调整 PostgreSQL 并发连接数
4. 操作系统层面调整
5. 常见问题与警告
6. 总结建议表

调整数据库的并发连接数是一个需要谨慎操作的任务,涉及数据库配置、操作系统和应用程序多个层面。目标并非越大越好，而是找到硬件、负载和稳定性之间的平衡点，过大可能导致资源耗尽、系统崩溃；过小则无法充分利用资源，导致请求排队。

以下是最主流两种数据库的调整方法：MySQL 和 PostgreSQL，同时也会涵盖操作系统层面的调优。

---

重要前提：调整前需要评估

1. 硬件资源：CPU核心数、内存大小（尤其是用于缓冲/缓存的内存）、磁盘I/O能力，每个连接通常需要消耗一定内存（如几MB到几十MB）。
2. 应用程序特性：是长连接（如Web服务连接池）还是短连接？高峰期并发请求量是多少？
3. 连接池限制：应用程序本身的连接池（如HikariCP、Druid、Tomcat JDBC）已经限制了从应用到数据库的连接数，数据库的max_connections应该大于所有应用实例连接池之和（留20-30%余量，用于管理、备份、监控等连接）。

---

调整 MySQL 并发连接数

动态调整（立即生效，重启后失效）

-- 查看当前最大连接数设置
SHOW VARIABLES LIKE 'max_connections';
-- 查看当前已使用的连接数
SHOW STATUS LIKE 'Threads_connected';
-- 动态修改（无需重启，但重启后失效）
SET GLOBAL max_connections = 500;

永久修改（需要重启MySQL服务）

修改配置文件 my.cnf 或 my.ini（Windows）：

[mysqld]
# 设置最大连接数为500
max_connections = 500
# 可选：设置连接超时时间（秒），防止僵尸连接消耗资源
wait_timeout = 600       # 针对非交互式连接（如程序连接）
interactive_timeout = 600 # 针对交互式连接（如命令行客户端）

高级监控与调优

• 监控连接命中率：计算 Max_used_connections / max_connections，这个比值如果经常接近1（如90%以上），说明连接数可能不够或应用连接池释放不及时。
• 查看连接状态：SHOW PROCESSLIST; 可以查看当前所有连接，找出大量处于 Sleep 状态的连接，它们可能是不正常的。
• 连接池配合：应用程序使用连接池时，建议将 max_connections 设为应用池大小总和加上50~100个额外余量。

---

调整 PostgreSQL 并发连接数

动态调整（需要重启，因为是一个配置参数）

PostgreSQL 的 max_connections 修改后几乎总是需要重启服务（通常不推荐在线修改生产环境的该参数，除非使用某些高级特性或扩展）。

-- 查看当前设置
SHOW max_connections;
-- 注意：SET GLOBAL在PG中不适用，必须修改配置文件

永久修改

修改配置文件 postgresql.conf：

# 设置最大连接数，默认通常是100
max_connections = 200
# 对于高并发场景，强烈建议配合连接池
# 可以设置共享缓冲区的内存大小，因为每个连接都需要分配内存
shared_buffers = 1GB      # 根据服务器内存调整，通常为物理内存的25%

提交修改后,需要重启 PostgreSQL：

# Linux
pg_ctl restart -D /var/lib/pgsql/data
# 或 systemctl restart postgresql

重要：PostgreSQL 与连接池

直接增加 max_connections 在PG中是非常低效的，甚至有害。 因为PG是进程模型（每个连接对应一个操作系统进程），连接数从100增加到500可能瞬间消耗大量内存和CPU上下文切换成本。

推荐做法：

• 保持 max_connections 在合理范围（如200~500）。
• 一定要使用外部连接池（如 PgBouncer，Pgpool-II）或应用层连接池。
• 这样,实际到数据库的连接数可以很低（如50-100），而通过连接池代理大量客户端请求。

---

操作系统层面调整

即使数据库参数设好了,操作系统也可能限制并发连接（特别是文件描述符限制）。

调整系统文件描述符限制

对于 Linux 系统，每一个TCP连接都需要一个文件描述符。

• 查看当前限制：ulimit -n
• 临时修改（当前会话有效）：ulimit -n 65535
• 永久修改（编辑 /etc/security/limits.conf）：

  # 为用户 mysql/postgres 或 * 设置
  mysql soft nofile 65535
  mysql hard nofile 65535
  *    soft nofile 65535
  *    hard nofile 65535

调整内核网络参数

在处理大量并发连接时,可以适当调整TCP参数（tcp_tw_reuse, tcp_fin_timeout 等，不过不同内核版本有差异，建议谨慎修改）。

---

常见问题与警告

1. 连接数过多导致OOM：如果max_connections设置得太大，而内存不足以支撑这么多连接，数据库会触发OOM Killer，导致服务中断。增加连接数的同时要确保有足够的物理内存。
2. 临界点效应：当连接数达到硬件瓶颈的某个阈值（例如CPU 90%或磁盘IO 100%），系统吞吐量可能急剧下降（性能悬崖），监控QPS和响应时间，找到那个拐点。
3. 应用端连接池泄漏：即使数据库max_connections设得很大，如果应用代码中有连接泄漏（只获取不释放），最终仍会耗尽连接。数据库的max_connections是最后一道防线，但不是解决方案。

总结建议表

数据库类型	常规单机推荐 max_connections	核心原则	配合措施
MySQL	500 ~ 2000（视内存和负载而定）	线程模型，可支持较多连接	使用应用层连接池；开启thread pool（企业版或Percona版）
PostgreSQL	100 ~ 400（特别不推荐超过500）	进程模型，连接数过多性能急剧下降	必须使用外部连接池（PgBouncer）
整体建议	从当前值逐步增加10%-20%，观察性能指标	连接数不是越高越好	监控 Threads_connected, QPS, 响应时间

操作顺序：

1. 检查当前连接数及使用率。
2. 评估预期需要多少并行长连接。
3. 先调整操作系统文件描述符限制。
4. 在数据库配置文件中增加max_connections并重启（或动态SET）。
5. 重启后,通过压力测试验证性能和稳定性。

如果你能提供更具体的场景（比如是哪种数据库、当前连接峰值、硬件配置、是否有连接池等），我可以给出更针对性的建议。