为什么需要连接池
建立数据库连接是一个代价高昂的操作：TCP握手、TLS协商、身份认证，通常需要数十毫秒。对于高并发应用，如果每个请求都建立新连接，连接建立的开销本身就会成为性能瓶颈。
同时，数据库服务器能够维持的最大并发连接数是有限的（PostgreSQL默认100）。每个连接都会占用服务器内存（约5-10MB），连接数过多会导致服务器内存不足并影响整体性能。
连接池通过维护一组预建立的连接，在请求之间复用这些连接，从而解决以上两个问题。
连接池的工作原理
-- 查看当前PostgreSQL连接状态
SELECT
state,
COUNT(*) AS connection_count,
MAX(NOW() - state_change) AS max_duration
FROM pg_stat_activity
WHERE datname = current_database()
GROUP BY state;
-- 查看等待队列（连接数接近上限时出现）
SELECT COUNT(*) AS waiting_queries
FROM pg_stat_activity
WHERE wait_event_type = 'Client'
AND wait_event = 'ClientRead';
-- 查看长时间空闲的连接（可能是连接泄漏）
SELECT pid, usename, application_name, state, state_change,
NOW() - state_change AS idle_duration
FROM pg_stat_activity
WHERE state = 'idle'
AND NOW() - state_change > INTERVAL '10 minutes'
ORDER BY idle_duration DESC;
连接池的三种模式：
| 模式 | 描述 | 适用场景 |
|---|---|---|
| Session模式 | 一个客户端会话独占一个数据库连接 | 需要会话级特性（临时表、事务） |
| Transaction模式 | 每个事务期间独占连接，提交后归还 | 大多数Web应用的推荐模式 |
| Statement模式 | 每条SQL语句独占连接（限制最多） | 只读查询、不使用事务特性 |
连接池参数配置指南
以PgBouncer（PostgreSQL专用连接池）为例：
; pgbouncer.ini 核心配置
[databases]
myapp = host=localhost port=5432 dbname=myapp
[pgbouncer]
; 监听配置
listen_addr = 127.0.0.1
listen_port = 5432
; 连接池模式
pool_mode = transaction
; 每个数据库-用户组合的最大连接数
default_pool_size = 20
; 最大客户端连接数（应用层最大并发数）
max_client_conn = 200
; 等待队列中超过此时间未获得连接则报错
query_wait_timeout = 5
; 空闲连接的保活时间
server_idle_timeout = 600
; 服务器连接的最大生命周期（防止长连接问题）
server_lifetime = 3600
连接数计算公式：
目标：数据库服务器的实际连接数 ≤ max_connections * 0.8（预留20%给管理员）
数据库服务器最大连接数（max_connections）= 100（默认）
可用连接数 = 80
如果有N个应用实例，每个实例的连接池大小 = 80 / N
例如：4个实例 → 每个实例 pool_size = 20
应用层最大并发数 = pool_size × 实例数 = 80
应用层连接池配置
以Node.js的pg-pool为例：
-- 与连接池配合，PostgreSQL端需要相应配置
-- postgresql.conf
-- max_connections = 100 -- 根据服务器内存调整
-- idle_in_transaction_session_timeout = 30000 -- 30秒，防止事务长时间挂起
-- statement_timeout = 60000 -- 60秒，防止慢查询拖垮连接池
-- 监控连接池健康状态的查询
SELECT
application_name,
state,
COUNT(*) AS connections,
AVG(EXTRACT(EPOCH FROM (NOW() - state_change))) AS avg_state_seconds
FROM pg_stat_activity
WHERE datname = 'myapp'
GROUP BY application_name, state
ORDER BY connections DESC;
常见连接池问题与排查
问题1：连接耗尽（too many connections）
-- 诊断：查找持有连接最久的进程
SELECT pid, usename, application_name,
query, state,
NOW() - query_start AS query_duration,
NOW() - state_change AS state_duration
FROM pg_stat_activity
WHERE datname = current_database()
ORDER BY query_duration DESC NULLS LAST
LIMIT 20;
-- 强制终止空闲超过5分钟的连接（谨慎使用！）
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = current_database()
AND state = 'idle'
AND NOW() - state_change > INTERVAL '5 minutes'
AND pid != pg_backend_pid();
问题2：连接泄漏
始终在应用层确保连接归还到连接池，特别是在异常处理路径中：
推荐模式（伪代码）：
pool.withConnection(async (conn) => {
// 无论是否抛出异常，连接都会自动归还
const result = await conn.query("SELECT ...");
return result;
});
避免：
const conn = await pool.acquire();
await conn.query("SELECT ...");
// 如果此处抛出异常，conn永远不会归还！
问题3：Serverless环境的特殊挑战
Lambda/Cloud Functions等无服务器函数每次调用都可能建立新连接：
-- 推荐使用Serverless专用连接池（如Neon Serverless、Supabase Pooler）
-- 或在函数外部初始化连接池，在调用之间复用
-- 监控Serverless场景下的连接情况
SELECT COUNT(*) AS short_lived_connections
FROM pg_stat_activity
WHERE datname = current_database()
AND NOW() - backend_start < INTERVAL '10 seconds';
使用Erdmates规划连接架构
在系统架构设计阶段，Erdmates的ERD帮助您理解数据访问模式——哪些服务访问哪些表，读写比例如何——这是合理规划连接池大小的基础信息。将连接池架构图与ERD结合，形成完整的数据访问层设计文档，供团队协作和架构评审使用。
连接池是数据库性能优化中投入产出比最高的手段之一。合理配置连接池，配合健康监控和自动恢复机制，可以将数据库层的可靠性提升一个量级。