为什么你的数据库在AI功能上线后崩溃：LLM感知的连接池设计

在AI功能上线之前，你的连接池一直运行良好。登录正常，仪表板加载顺畅，CRUD操作以个位数毫秒的延迟稳定运行。然后团队部署了一个RAG驱动的搜索、一个Agent驱动的工作流，或者一个LLM支持的摘要端点——几个小时内，你的核心产品开始超时。数据库并没有变慢，你的连接池只是被一种它从未被设计来处理的工作负载吞噬了。

这就是LLM连接池问题，随着AI功能从原型走向生产环境，它正在影响整个行业的团队。解决方案不是"增加更多连接"。事实上，这通常会让事情变得更糟。

根本性的不匹配：Web流量 vs AI工作负载

传统连接池是为Web应用流量设计的：短暂的请求获取一个连接，执行一个快速查询（通常1-10ms），然后释放它。一个20个连接的池可以轻松地每秒处理数百个请求，因为每个连接只被持有很短的时间窗口。

AI驱动的功能打破了这个模型所依赖的每一个假设。

一个RAG检索管道可能需要持有一个连接进行向量相似度搜索（50-200ms），然后再次持有它进行元数据查找，然后再次用于上下文窗口组装查询——这一切都发生在LLM开始生成token之前。Agent工作流更糟糕：它可能在多步推理链中执行5-15个数据库操作，在数秒而非毫秒的时间跨度内间歇性地持有连接。

数学算不过来了。如果你的平均连接持有时间从5ms跳到500ms，你的有效池吞吐量下降了100倍。那些每秒处理400个请求的20个连接现在只能处理4个。你的排队队列填满，超时级联扩散，而登录页面——只需要一个2ms的查询——因为所有连接都被一个正在决定下一步做什么的Agent占用而无法获得连接。

AI工作负载摧毁连接池的三种方式

扇出放大

AI功能中的单个用户操作通常会触发数据库查询的扇出。用户提出一个问题，在后台系统运行嵌入查找、检索10个候选文档、获取每个文档的元数据、检查访问权限、加载对话历史并写入审计日志。对负载均衡器来说看起来像一个请求的东西，实际上是15-20个数据库操作，每个都需要一个连接。

传统Web端点有可预测的扇出比率——通常每个请求1:1到1:3个查询。AI端点通常达到1:10或更高。当你乘以并发用户数时，连接需求的峰值是非线性的。十个并发AI请求不需要10个连接；它们需要150个。

外部调用期间持有连接

这是最隐蔽的模式。许多实现在等待LLM API响应时保持数据库连接打开——这个调用需要1-30秒。开发者并非有意为之；这是因为数据库查询和LLM调用在同一个事务、同一个请求处理器或同一个ORM会话范围内。

一个在LLM调用期间持有10秒的连接，意味着2000个正常查询无法使用这个连接。如果你的池有25个连接，其中5个卡在等待LLM响应上，你已经失去了20%的容量给本质上的空闲等待。

重试放大

AI功能比传统端点更容易失败。LLM超时、向量数据库没有返回结果、Agent的工具调用遇到速率限制。当这些失败触发重试时——它们几乎总是会——每次重试都会重新执行整个数据库扇出。一个带有3次重试和10个查询扇出的单个失败AI请求会产生40个数据库操作而不是10个。

结合更长的持有时间，重试放大会产生惊群效应。池已经处于压力之下，重试堆积更多负载，检出超时增加，这又触发更多上游重试，突然你陷入了一个反馈循环，导致整个应用程序崩溃——不仅仅是AI功能。

连接池分段：核心架构模式

解决方案不是更大的池。而是分离的池。连接池分段将AI工作负载与核心产品隔离，使一方无法饿死另一方。

最简单的版本使用两个池：

• 核心池：专门为现有产品保留。登录、仪表板查询、CRUD操作。这个池有保证的最小连接数，任何AI工作负载都无法触及。
• AI池：专用于LLM驱动的功能。这个池有自己的限制、自己的超时和自己的熔断器。如果它耗尽了，AI功能降级——但核心产品继续运行。

在实践中，这意味着你的AI服务层获得一个指向独立PgBouncer实例的单独数据库连接字符串（或同一个连接池中配置了独立限制的单独池）。AI池可能有default_pool_size = 15和激进的server_idle_timeout，而核心池有default_pool_size = 30和标准设置。

一些团队更进一步采用三层分段：核心、AI读取（用于检索和嵌入查找）和AI写入（用于审计日志、对话历史、反馈存储）。这可以防止突发的写密集型Agent活动阻塞依赖读取的检索管道。

准入控制：缺失的一环

连接池分段告诉你哪个池处理哪种工作负载。准入控制告诉你是否接受这个请求。

加载中…