db.DB().Stats() 无法直接统计连接持有时间分布，但可通过 InUse 长期接近 MaxOpenConns 且 Idle 长期为 0 反推连接被长期占用；WaitDuration（Go 1.21+）突增、WaitCount 线性上涨、InUse 持续不降等现象可辅助定位未归还连接问题。
怎么用 db.DB().Stats() 看连接持有时间分布
连接持有时间（即一个连接从被取出到归还池子的时长）无法直接统计，db.DB().Stats() 不提供直方图或 P95/P99 指标，但能通过 InUse 和 Idle 的变化趋势反推——如果 InUse 长期接近 MaxOpenConns 且 Idle 长期为 0，说明连接被长期占用，没及时释放。
实操建议：
- 在压测前后高频采样
db.DB().Stats()，重点关注InUse峰值是否持续 >90%、WaitCount是否线性上涨（说明 goroutine 在排队等连接） -
WaitDuration字段（Go 1.21+）可直接反映等待总耗时，若该值在 1 秒内突增，基本确认存在连接持有过久或未归还问题 - 搭配日志打点：在
db.Raw().Rows()后、rows.Close()前记录起止时间；在tx.Begin()和tx.Commit()/Rollback()之间埋点，定位具体哪类操作拖长了持有时间
为什么 rows.Close() 或 tx.Rollback() 漏掉会导致连接“假死”
连接不会自动归还池子，必须显式结束资源生命周期。漏掉 rows.Close() 会让连接卡在 InUse 状态，即使 SQL 执行完了也仍被标记为“正在使用”；漏掉 tx.Rollback()（尤其在 error 分支）则事务连接永远不释放，MySQL 侧可能显示 idle in transaction。
常见错误现象：
- DB 端
SHOW PROCESSLIST出现大量Sleep或idle in transaction状态连接 -
db.DB().Stats().InUse持续不降，哪怕并发请求已结束 - 新请求开始报
context deadline exceeded或卡在acquireConn内部
如何用 SQL 层 ID 追踪单个连接复用路径
MySQL 的 CONNECTION_ID() 可以验证连接是否真的被复用。在 GORM 查询中嵌入该函数，对比多次请求返回的 ID 是否相同，就能判断连接池是否生效、以及某次查询是否意外新建了连接。
示例写法：
var connID int64
db.Raw("SELECT CONNECTION_ID()").Scan(&connID)
log.Printf("connection id: %d", connID)
注意点：
- 必须在同一次
db实例上调用，跨db.Session(&gorm.Session{})或db.WithContext()可能触发新连接 - 避免在事务内调用后又忘记
tx.Commit()，否则该连接 ID 对应的连接会一直挂起 - 云数据库（如 RDS）可能做连接透传，看到的 ID 是代理层分配的，需结合
SHOW PROCESSLIST中的Id列交叉验证
SetConnMaxLifetime 设太短反而掩盖真实持有问题
SetConnMaxLifetime 是强制“到期销毁”，不是“健康检测”。设成 30 秒，会让所有存活超时的连接在下次复用前被关掉——这会把本该暴露的“连接未归还”问题掩盖成“频繁重连”，导致 WaitCount 看似不高，但 Open 值剧烈抖动、CPU 消耗升高。
真正要分析持有时间分布，得先禁用它（设为 0），让连接自然流转，再观察 InUse/Idle 的稳定性和延迟毛刺点。等确认代码中无泄漏后，再按 MySQL wait_timeout 值设回 240s 左右。
容易忽略的一点：SetConnMaxLifetime 不影响当前正在 InUse 的连接，只作用于空闲后准备复用的连接。所以它救不了“忘了 Close()”的问题，只会让问题更难定位。
