Nginx 开源版 stream 模块不支持 least_time 算法，仅支持 round_robin、least_conn、hash 和 random；因其纯字节流透传设计，无法解析协议获取响应时间。
Nginx 的 stream 模块不支持 least_time 负载均衡算法。
这个算法仅存在于 Nginx Plus（商业版）的 http 模块中，用于七层 HTTP 代理；而开源版 Nginx 的 stream 模块（包括所有稳定发行版）只支持以下四种四层上游调度算法：
-
round_robin（默认，轮询） -
least_conn（最少活跃连接） -
hash $variable（一致性哈希，支持consistent参数） -
random（随机，可加two参数实现随机双选）
least_time 要求实时采集后端响应时间（如 last_byte 或 first_byte 延迟），这依赖于应用层协议解析和精细指标统计——而 stream 模块设计原则是零协议解析、纯字节流透传，无法获取 MySQL/Redis 等协议中的“响应完成”语义，因此技术上无法实现该算法。
如果你的目标是降低数据库代理时延，可通过以下方式在 stream 模块中有效逼近类似效果：
启用连接复用与快速失败机制
避免把请求发给已变慢或卡顿的节点，比“挑最快”更实际：
- 设置较短的
proxy_connect_timeout 1s：快速丢弃建连慢的后端 - 启用
proxy_responses 1：等待首个数据包再确认连接可用，防止 TCP 握手成功但 mysqld 实际卡死的误判 - 配合
max_fails=2 fail_timeout=10s：连续两次无响应即摘除，10 秒内不重试
用 least_conn + 权重动态调优
对长连接密集型数据库场景更合理：
-
least_conn天然倾向将新连接分发给当前负载更轻的节点（连接数少 ≈ 当前处理压力小） - 可结合监控（如
SHOW PROCESSLIST连接数、CPU 使用率）手动调整weight，例如：-
server 10.0.1.10:3306 weight=5;（性能强的主库） -
server 10.0.1.11:3306 weight=3;（稍弱的从库）
-
前置网络与系统级优化
真正影响时延的关键常在代理之外：
- 开启
so_keepalive on：避免中间防火墙或 NAT 设备主动断开空闲连接，减少重连延迟 - 增大
proxy_buffer_size 512k：防止大查询结果被截断重传 - 确保 Nginx 服务器与数据库同机房、低 RTT（<1ms），跨机房时
least_time即使存在也意义有限
不复杂但容易忽略。
