一句话定义
连接池（Connection Pooling）就是在程序启动时先建好一小批到数据库的连接，之后每个请求都从这批连接里"借一条用、用完还回去"，而不是每次查询都新建一条、用完就关。
为什么"新建连接"这么贵
一次数据库连接，用户看到的只是"连上了"，底下发生的事却不少：TCP（Transmission Control Protocol）三次握手，数据库端的身份认证，服务端为这个会话分配内存、进程或线程、会话变量，客户端也要维护缓冲区。这一套走完，往往几十到几百毫秒。而真正执行一条简单查询，可能只要一两毫秒。
打个比方：你要问客服一个问题，每次都得拨号、听彩铃、报身份证号、问完立刻挂断。说了十秒钟的话，前戏花了两分钟。连接池就是那条一直不挂的专线——拿起就说，说完放回话机，下一个人接着用。
池子太小会排队，太大又会打爆数据库
连接池的大小是一个典型的"两头都疼"的参数。
池子太小：请求来了没连接可用，只能排队等。表现为平均延迟还行，但 P99 突然飙高，高峰期大量"获取连接超时（connection timeout）"报错。注意，瓶颈不一定在数据库——数据库可能很闲，是你的应用在自己卡自己。
池子太大：每条连接在数据库里都是实打实的资源。连接数上去以后，数据库要花更多 CPU 在会话调度和上下文切换上，锁竞争和内存占用也变大，单条查询反而变慢。更糟的是，每个数据库都有最大连接数上限（max_connections 之类），撞上限时新的连接会被直接拒绝，连管理员都挤不进去。
所以经验上，最优池大小往往比直觉小得多——因为查询很快就归还连接了，十几条连接支撑相当大的吞吐并不稀奇。具体默认值和上限请以你用的连接池库和数据库官方文档为准。
和相邻概念的区别
| 概念 | 池化的对象 | 省掉的开销 |
|---|---|---|
| 连接池 | 数据库/服务连接 | 握手、认证、会话初始化 |
| 线程池（Thread Pool） | 操作系统线程 | 线程创建与销毁 |
| 长连接 / keep-alive | 同一条 TCP 连接本身 | 重复的 TCP 握手 |
三者思路相同，都是"别反复建、反复拆"。连接池通常是跑在长连接之上的：keep-alive 负责"不挂断"，连接池负责"谁用、用多久、什么时候回收"。
对从业者的实际意义
配连接池时至少要关心这几个旋钮：最大连接数、获取连接的超时时间、空闲回收、连接最大存活时间、借出前的健康检查。最容易踩的坑是连接泄漏（connection leak）——代码借了连接但异常路径上没还，池子被慢慢抽干，最后所有请求都在等一个永远不会回来的连接。用 try-with-resources 或上下文管理器，配合超时强制回收，基本能兜住。
另外，在无服务器（serverless）架构里，每个函数实例都自带一个小池子，实例一扩容，总连接数等于"实例数 × 池大小"，很容易把数据库打爆。这时通常要在应用和数据库之间放一层连接代理，把众多客户端收敛成少量后端连接。
对不做技术的人，这套逻辑其实很通用：窗口开太少大家排队，开太多柜台自己也乱。资源复用这件事，从来是找平衡，不是越多越好。