连接池
Connection Pool
高级通用连接池（Connection Pool）是应用预先建立并重复使用的一组数据库连接，请求需要访问数据库时从中借用，用完归还。因为建立连接有开销、数据库能承受的连接数也有限，它能减少反复建连，并控制同时使用的连接数。
你可能会说：「网站一忙起来就反复连接数据库，速度变慢。我想让请求复用连接，同时别把数据库撑满。」
动手看看下单查询复用数据库连接
1
下单服务要查订单，先向连接池借一条空闲连接。池里已经备好了连接，不必为这次请求重新建立。
要点连接池是怎么让请求共用连接的？
- 1
借到连接才能访问数据库
你做一个订单后台，多个请求可能同时查订单。每个请求访问数据库前从池里借一条连接，操作结束后归还，下一次请求就能继续用。归还的是连接，不是把查询结果留给别人。
- 2
连接数量和等待时间要受控
池里的连接不是越多越好，因为数据库也有连接上限。连接都被借走时，新请求通常要等待空闲连接；等得太久则会超时。设置池大小时，要一起看数据库容量和应用实例数量。
- 3
用完归还也包括失败路径
如果请求报错后没归还连接，池会逐渐被占满，后来的请求只能等待。让 AI Agent 实现时，你可以让它检查正常返回、异常和事务结束时是否都会释放连接。
容易混淆的地方
连接池管理的是数据库连接，不是缓存：缓存保存可复用的数据，命中时可能根本不用查数据库；连接池仍然会执行查询。它也不是全站共用的一条连接：多个请求可以借用池中不同的连接。多个应用实例通常各有自己的池，所以总连接数要合起来看。
什么时候用
适合用
- 做电商后台或 SaaS 网站，多个用户会同时读取、修改数据库中的数据，适合让请求复用连接。
- 部署了多个后端实例，每个实例都频繁查询数据库，需要控制各实例的池大小，避免总连接数过高。
- 做持续运行的消息消费者，处理每条消息都要写数据库，复用连接可减少反复建连。
不适合用
- 页面只展示构建时生成的静态内容，运行时不访问数据库，就不需要连接池；直接提供静态文件即可。
- 一个只运行一次、顺序执行少量查询的本地脚本，直接建立连接并在结束时关闭，通常比引入连接池简单。
练一练选一个答案，看看解释
你的订单后台有多个后端实例。流量上来后，数据库连接数接近上限，但每个实例的连接池看起来都没满。下一步更合理的是？
让 AI 帮你做复制给 AI Agent 直接用
请检查这个后端访问数据库的方式：如果请求中频繁新建连接，请改为使用连接池，并说明池大小、等待超时如何配置。检查正常返回和报错时连接是否都会归还；如果有多个应用实例，也请估算它们合计可能占用的连接数。