数据库连接池是什么？连接数为什么不是越大越好，借出的连接怎么归还？

知识点详解：一个连接，从借出到再次可用

池中连接，不是每个请求私有的新对象

假设应用有一个共享连接池，里面维护几条可用数据库连接。

请求 A 取得一条，执行查询，使用结束后归还。请求 B 随后可以再用这条连接，不必每次都重新建立完整会话。

node-postgres 的池文档与Psycopg 连接池文档都说明了借用、归还与资源关闭的关系。

连接会保留数据库会话相关状态，因此，还要按驱动与池的约定处理事务、连接失效及必要的状态清理。不是塞进池里以后就永远健康，也不是每次归还都保证任意自定义会话设置自动消失。

哪一段时间算“占用连接”？

从池成功借出，到调用方归还，这整段时间连接都不能随便给别的请求并用。

如果取得连接后先请求一个慢外部服务，再执行一条很快的 SQL，连接仍被长时间占着。池统计看到的是占用，不会替代码判断“这段时间没有真正查数据库，应该忽略”。

所以，优化连接持有范围常常比增加上限更直接。先准备无需连接的工作，再借用；不需要继续查询后，及时归还。

不过，事务里不能为了“快点还连接”随意把后续步骤换到另一条连接。事务状态属于连接会话，完整事务必须保持正确边界。

归还要覆盖成功和失败路径

以下用 PostgreSQL 驱动展示同一意图：共享池，查询时借用，结束后归还。它不是 Java HikariCP API 的机械翻译。

TypeScript / node-postgres：

import { Pool } from "pg";

const pool = new Pool({ max: 10, connectionTimeoutMillis: 2000 });

export async function ping(): Promise<number> {
  const client = await pool.connect();
  try {
    const result = await client.query("SELECT 1 AS ok");
    return result.rows[0].ok;
  } finally {
    client.release();
  }
}
// pool.end() 留给应用关闭阶段，不要每次请求都调用。

Python / psycopg_pool：

from psycopg_pool import ConnectionPool

pool = ConnectionPool(min_size=0, max_size=10, timeout=2, open=False)
pool.open()

def ping() -> int:
    with pool.connection() as conn:
        row = conn.execute("SELECT 1 AS ok").fetchone()
        assert row is not None
        return row[0]

# pool.close() 留给应用关闭阶段。

连接参数应由实际项目安全配置提供，这里不放生产地址。Python 的 connection 上下文还按约定处理事务提交或回滚；TS 的 release 不会替你自动完成一个手动开启的事务，这个差异必须说清。

单次查询也可以使用驱动提供的池便捷方法，减少手动借还。涉及多语句事务时，则明确使用同一连接及提交、回滚策略。

池满，是症状，不是原因

活跃连接很多、SQL 本身很慢：先查执行计划、IO、锁等待和负载，不要直接加连接。

SQL 很快，但连接迟迟不还：查是否在等待外部工作、长事务或处理大批结果。

业务流量下降后占用仍不回落：查失败路径或资源泄漏。扩大池只能让耗尽来得晚一些，不能修复泄漏。

如果数据库还有余量、查询与持有范围合理，当前上限确实限制吞吐，才可以通过压测逐步调整。要一起看池等待时间、数据库负载和请求尾延迟，而不是只看连接数变大了。

多个实例，要合起来算预算

12 个实例，每个 max=30，配置层面的潜在总量是 360；如果每个实例还有多个独立进程或池，预算还要再合并。

这不是说 360 条连接启动时一定全部打开，实际建立时机受最小数量和池实现影响。但数据库容量规划必须考虑上限可能同时被使用。

还需要给管理、迁移、其他服务以及故障切换等留空间。不能把数据库允许的最大连接数，全部分给一个业务池。

HikariCP 的池大小讨论也提醒，过多连接未必有更好性能。公式只能作为特定假设下的起点，实际仍应按数据库和任务负载验证。

面试官继续追问

获取超时，就是 SQL 执行超时吗？

不是。前者是在等可用连接，后者是查询执行边界。还可能有请求总截止时间，需要分层安排。

归还之后，还能拿这个 client 查询吗？

不应该。它可能已经被别人借用。归还以后，调用方就结束这次使用权，不能继续操作。

每次请求创建一个新 Pool，会更独立吗？

会破坏共享复用，也容易放大连接预算。通常在应用适当生命周期内共享池，关闭时统一释放。

面试速记卡

• 连接池：复用数据库会话，并限制同时占用。
• 生命周期：借用、执行、归还；归还不等于关闭底层连接。
• 池满：查慢查询、持有范围和泄漏，再决定是否扩容。
• 总预算：合并所有实例、进程、池和其他客户端。
• 超时：等待连接、执行 SQL、请求截止时间分别设置。