是，SetMaxOpenConns设太高反而拖慢请求；因其远超数据库max_connections或业务实际并发时，引发连接争抢、锁等待和连接拒绝，导致PING成功但Query超时、Too many connections错误及CPU syscall高占用。
Go应用里db.SetMaxOpenConns设太高反而拖慢请求？
不是越大越好。当SetMaxOpenConns远超数据库服务器允许的最大客户端数（如MySQL默认151），或超出业务实际并发能力时，连接争抢、锁等待、甚至连接拒绝会立刻暴露。
典型现象：PING成功但Query超时、Too many connections错误频发、CPU在syscall.Syscall上持续高占用。
- 先查数据库侧上限：MySQL执行
SHOW VARIABLES LIKE 'max_connections'; - 再算应用侧真实并发：按QPS × 平均查询耗时估算活跃连接数，留20%余量
- 生产建议值：通常
SetMaxOpenConns设为20–50，绝不超过数据库max_connections的70%
为什么db.SetMaxIdleConns必须≤SetMaxOpenConns？
这是硬约束。如果SetMaxIdleConns(20)但SetMaxOpenConns(10)，Go runtime会在sql.Open后立即panic，报错maxIdleConns(20) is greater than maxOpenConns(10)。
根本原因：空闲连接本质是“已打开但未使用”的连接，它必须从MaxOpenConns池子里划出来。逻辑上不可能有比总池子还大的空闲子集。
- 安全配法：
SetMaxIdleConns≤SetMaxOpenConns，且建议设为后者的1/2～1/3 - 低流量服务可设
SetMaxIdleConns = SetMaxOpenConns，避免频繁建连 - K8s滚动发布时，若
IdleTimeout没配合readinessProbe，旧Pod可能持着空闲连接不释放
Kubernetes环境下ConnMaxLifetime怎么避坑？
SetConnMaxLifetime不是“保活”，而是“强制淘汰”。设太短（如5分钟）会导致连接高频重建；设太长（如24小时）又可能撞上云厂商LB的连接空闲超时（常见4–6分钟）或数据库侧wait_timeout（MySQL默认8小时，但很多云DB实为30分钟）。
关键对齐点：必须小于所有中间链路的空闲断连阈值，且大于应用单次请求最大耗时。
- 查K8s Service的
sessionAffinity和底层云LB配置（如AWS NLB默认3500秒） - 查数据库
wait_timeout：MySQL执行SHOW VARIABLES LIKE 'wait_timeout'; - 推荐值：
SetConnMaxLifetime(5 * time.Minute)，比LB超时小至少1分钟
连接泄漏最常被忽略的三个位置
泄漏不只发生在db.Close()——那是整个池的关闭。真正泄漏的是单次查询后没归还的连接，根源几乎都藏在rows、tx、stmt生命周期管理里。
-
rows没defer rows.Close()：尤其在for rows.Next()中途return或panic时，连接卡在InUse状态不动 -
sql.Tx没Commit()/Rollback()：事务开启后未结束，连接永远被占用 - 用
db.Prepare()后没调stmt.Close()：预编译语句本身不占连接，但其底层可能复用连接池资源，长期不关会间接阻塞连接回收
验证泄漏：定期调db.Stats()，紧盯InUse持续上涨而Idle趋零，基本就是上述某处漏了Close或Rollback。
