引言：连接数打满的常见原因与影响

数据库连接数打满是运维和开发场景中常见的问题，通常表现为应用报错“too many connections”或请求超时。原因包括：应用未正确释放连接、连接池配置过大、突发流量超出预期、慢查询导致连接长时间占用等。该问题会直接导致服务不可用，需要快速定位并调整。

定位当前连接状态

在调整前，需确认连接数是否真正到达上限。以下是主流数据库的查询方法：

• MySQL：SHOW VARIABLES LIKE 'max_connections'; 查看最大连接数；SHOW STATUS LIKE 'Threads_connected'; 查看当前已用连接数；SHOW PROCESSLIST; 查看活动连接详情。
• PostgreSQL：SHOW max_connections; 查看上限；SELECT count(*) FROM pg_stat_activity; 获取当前连接数。
• SQL Server：SELECT @@MAX_CONNECTIONS; 查看最大连接数；SELECT COUNT(*) FROM sys.dm_exec_sessions; 获取当前会话数。

调整方法

1. 临时调整数据库连接数上限

适用于紧急恢复，但重启后会失效（除非修改配置文件）。

• MySQL：SET GLOBAL max_connections = 500; 注意：新增值需小于系统资源允许的上限。
• PostgreSQL：修改postgresql.conf中的max_connections，然后执行pg_ctl reload或SELECT pg_reload_conf();。
• SQL Server：使用sp_configure 'max user connections', 500; RECONFIGURE;（企业版支持在线调整）。

注意：临时提升连接数仅缓解症状，若应用本身存在连接泄漏或频繁慢查询，可能短时间内再次打满。

2. 应用层优化：连接池与代码规范

连接泄漏是根因之一。建议措施：

• 使用连接池（如HikariCP、Druid、C3P0），并合理设置maximum-pool-size（通常为20~100，视并发和响应时间而定）。
• 应用代码中确保finally块关闭连接，或使用try-with-resources（Java）等自动回收机制。
• 设置连接超时（connectionTimeout）和空闲超时（idleTimeout），避免僵尸连接。

3. 长期架构优化

若业务连接需求持续增长，需考虑：

• 读写分离：将读请求分流到只读副本，减少主库连接压力。
• 分库分表：将数据分散到多个数据库实例，各实例独立承载连接。
• 缓存层：引入Redis或Memcached，降低数据库查询频率。
• 慢查询治理：通过慢日志分析并优化SQL，缩短连接占用时间。

调整时的注意事项

• 连接数上限受服务器内存、CPU、网络文件描述符限制。MySQL每个连接约占用2~3MB内存，PostgreSQL约5~10MB；调整前应评估剩余内存。
• 操作系统层面：检查ulimit -n（Linux开放文件描述符数）是否足够，必要时修改/etc/security/limits.conf。
• 不要一次性将连接数调得过高，建议逐步增加并监控系统负载，避免OOM。

总结

数据库连接数打满的调整需“治标+治本”。临时提升max_connections作为应急手段，同时从应用层优化连接使用、代码规范入手，并结合读写分离、分库分表等架构方案。定期巡检连接数和慢查询日志，是预防该问题的关键。运维人员应将连接数纳入监控告警体系，设置合理的阈值（如最大连接数的80%触发预警）。