Nginx least_conn 不直接连接数据库，而是将请求分发给应用服务，数据库连接池爆满源于应用层连接复用不当、慢查询或流量倾斜；需确认 upstream 配置正确、版本支持，并分层定位瓶颈。
排查 Nginx least_conn 模式下后端数据库连接池爆满，核心不是 Nginx 本身在“连数据库”，而是它把请求分发给应用服务（如 Java/Python 服务），而这些服务再连接数据库；least_conn 只影响 Nginx 到上游应用的负载分发逻辑。真正导致数据库连接池爆满的，往往是应用层未合理复用连接、慢查询堆积、或 Nginx 分发不均放大了局部压力。
确认 Nginx 的 upstream 确实用了 least_conn
检查配置中是否明确启用了该算法，且无其他干扰设置：
- 确保
upstream块中包含least_conn;，而非默认的轮询（round-robin）或 ip_hash - 排除
weight、max_fails、fail_timeout等参数意外导致某台上游被持续剔除，造成流量倾斜 - 验证 Nginx 版本 ≥ 1.3.1（
least_conn引入版本），旧版本不支持该算法
查清真实瓶颈在“应用”还是“数据库”
least_conn 关注的是上游服务器当前活跃连接数，但数据库连接池满，通常源于应用服务内部行为。需分层定位：
- 登录各应用服务器，用
netstat -anp | grep :3306 | wc -l（MySQL）或对应端口，看每台机器建了多少到 DB 的连接 - 对比 Nginx 的
$upstream_addr日志字段，确认连接数多的后端，是否恰好是日志中被频繁选中的那几台 - 检查应用自身连接池监控（如 HikariCP 的
ActiveConnections、Druid 的ActiveCount），确认是否真达到 maxActive/maxPoolSize
分析 least_conn 是否加剧了连接倾斜
least_conn 在高并发短连接场景下可能失效：新连接建立快、释放慢，Nginx 统计的“当前连接数”滞后于实际资源占用。例如：
- 某台应用因 GC 或慢 SQL 响应变慢，连接堆积未及时关闭，Nginx 认为它“连接少”，继续导流，形成恶性循环
- 大量请求集中在某个热点接口（如登录、下单），该接口在某台机器上执行时间长，导致其连接数“看起来少”，却被持续打满
- 建议开启 Nginx 连接统计日志：
log_format upstream '$remote_addr - $upstream_addr -$upstream_response_time ms';，结合时间维度分析分发分布
针对性优化建议
不改算法也能缓解问题：
- 在应用侧收紧数据库连接池：降低
maxLifetime、启用connection-test-query，及时清理僵死连接 - 对 Nginx upstream 添加
keepalive 32;并在 location 中配置proxy_http_version 1.1; proxy_set_header Connection '';，复用到应用的连接，减少频繁建连带来的抖动 - 若确认某台应用长期响应慢，临时用
down或max_fails=1 fail_timeout=10s主动隔离，避免 least_conn 把它当“轻载”节点 - 必要时换用更稳定的负载策略：如
ip_hash（会话粘性）或基于响应时间的least_time header（需商业版或 OpenResty）
