Node.js异步非阻塞I/O场景下是否仍需数据库连接池？

兄弟，你的问题问到点子上了——很多刚吃透Node异步模型的开发者都会有这个疑惑：既然await能让事件loop不被阻塞，为啥还要搞连接池？我来给你掰扯清楚核心原因：

首先得肯定你对Node异步非阻塞的理解：你说的没错，当await db.query()执行时，Node确实会把这个I/O任务丢给libuv，然后转头去处理其他请求，等数据库返回结果再回来继续执行函数。但问题不在Node这边，而在数据库和TCP连接的本质特性上：

• 单个数据库连接是串行处理请求的
  数据库服务器不会在同一个TCP连接上并行处理多个查询——不管Node有多异步，只要你用的是同一个Client连接，第一个请求发了查询之后，这个连接就被占住了，直到数据库把这个查询的结果返回、连接释放，第二个请求才能用它发下一个查询。
  举个实际的例子：假设你的/price接口每次查询要100ms，用单连接的话，1000个并发请求过来，最后一个请求得等前面999个全处理完才能轮到，总耗时要100秒；但如果用连接池，比如池大小设为10，那就能同时处理10个查询，总耗时直接降到10秒左右，并发能力一下就上来了。

• 频繁创建销毁连接的成本极高
  要是你不用连接池，每次请求都新建一个Client（连接数据库、认证、握手），这些步骤的耗时可能比你的查询本身还久——TCP三次握手、数据库身份校验这些操作都是实打实的开销，复用连接能把这部分成本完全省下来。连接池就是提前帮你建好一批连接，请求来就拿，用完就放回池里待命，完全不用重复走建立连接的流程。

• 数据库的并发资源限制
  数据库本身能同时处理的连接数是有限的，而且连接数也不是越多越好——太多的连接会让数据库频繁切换上下文，反而拖慢性能。连接池的好处就是能帮你控制并发连接数（比如PostgreSQL一般建议池大小设为(CPU核心数*2)+1），让数据库的资源利用更高效，不会过载也不会闲置。

再回到你用的pg库：如果你用单个Client实例，就算你写了异步代码，也会变成串行处理请求，完全发挥不出Node的并发优势。而用Pool的话，它会自动帮你管理多个Client，每个请求分配空闲连接，执行完回收，甚至还会自动处理连接断开后的重连，比你自己维护单Client靠谱多了。

所以结论很明确：别纠结了，直接用Pool就对了，单Client只适合脚本化的单次操作（比如一次性导数据），绝对不能用在Web服务的高并发场景里。

内容来源于stack exchange