least_conn不适用于数据库连接池动态平衡，因其仅作用于负载均衡器可见的TCP连接，无法感知应用层数据库连接池的内部状态，且数据库长连接特性使连接数指标失真。
least_conn 是一种负载均衡算法，但它不适用于数据库连接池的动态平衡，也不能直接用于后端数据库连接数的调度。这是常见误解——需要先厘清概念边界。
least_conn 的真实适用场景
least_conn 是 LVS、HAProxy、Nginx 等反向代理或四层/七层负载均衡器中的一种调度策略，其逻辑是：将新请求转发给当前活跃连接数最少的后端服务器。它面向的是 TCP 连接（如 HTTP 请求连接、长连接网关），而非数据库驱动内部维护的连接池。
数据库连接（如 MySQL 的 JDBC Connection、PostgreSQL 的 pgconn）由应用层连接池（如 HikariCP、Druid、pgBouncer）管理，负载均衡器无法感知这些连接的建立、使用与释放。
为什么不能用 least_conn 平衡数据库连接数
- 数据库客户端直连数据库时，中间没有代理层拦截或重写连接，least_conn 无处生效
- 一个应用实例可能持有多达几十上百个连接池连接，而负载均衡器只看到该实例的一个 IP:Port 入口，无法穿透统计内部连接数
- 数据库连接是长生命周期、复用频繁的资源，和 HTTP 短连接行为差异大，least_conn 的“连接数”指标在此失真
- 即使使用数据库代理（如 ProxySQL、MySQL Router），它们也通常采用会话保持、查询路由或权重轮询，而非 least_conn —— 因为连接数低未必代表负载低（例如空闲连接多但正在执行慢查询）
真正可行的数据库连接负载平衡方案
要实现后端数据库连接的合理分担，需从应用架构与连接池配置入手：
- 统一连接池配置：所有应用实例使用相同的最大连接数（maxPoolSize）、最小空闲连接（minimumIdle）、连接超时等参数，避免某实例过度抢占连接
- 按实例维度限流与熔断：通过服务网格（如 Istio）或 SDK（如 Sentinel）控制单实例对数据库的并发调用数，间接约束其连接池使用上限
- 读写分离 + 分库分表路由：将流量按逻辑拆分到不同数据库实例，比单纯靠连接数均衡更有效且可预测
- 引入中间代理层（谨慎选择）：如 pgBouncer（transaction 或 session 池模式）、ProxySQL（支持 query rule + 后端健康检查），它们可集中管理连接并提供简单负载策略，但并非 least_conn，而是基于权重、延迟或状态的路由
如果坚持要在代理层模拟“连接数感知”
极少数场景下，可通过定制手段近似实现：
- 让每个应用在启动时向注册中心（如 Nacos、Consul）上报自身连接池活跃数，并定时刷新
- 网关或 Sidecar 订阅该指标，结合自定义 LB 插件，在转发数据库请求前选择活跃连接数较低的实例
- 注意：这要求应用主动暴露指标、网络可靠、延迟可控，且仅适用于数据库请求经由网关代理（如 gRPC 数据库封装服务），不是标准 JDBC 场景
不复杂但容易忽略：数据库负载均衡的关键从来不在“连接数”，而在查询分布、事务粒度、连接生命周期管理与资源隔离。least_conn 是一把好刀，但切数据库连接这个“瓜”，它根本没对准位置。
