Go数据库连接池不自动剔除慢连接，仅处理死连接；必须用context.WithTimeout包裹每次Query/Exec等操作来拦截超时，避免慢查询占用连接拖垮池子。
Go 中的数据库连接池本身不自动剔除“慢连接”，只负责剔除“死连接”或“失效连接”。所谓慢连接（比如查询执行超时、网络延迟高、锁等待长），必须靠上层主动控制或配合超时机制来拦截，否则会持续占用连接并拖垮整个池。
sql.DB 的默认行为根本不管“慢”，只管“死”
Go 标准库 database/sql 的 sql.DB 本身是个连接池抽象，但它不做任何“响应时间检测”——它只在获取连接时尝试复用空闲连接，归还时不验证是否还活着，也不记录该连接上次用了多久。
常见错误现象包括：
- 某个连接卡在
SELECT ... FOR UPDATE上 5 秒，后续请求从池里拿到它，也得等完这 5 秒才开始执行 - 数据库主从切换后，部分连接仍连着旧从库，查询变慢但没报错，池子照常分发
- 网络抖动导致某连接读取阻塞，
QueryRow卡住，Goroutine 挂起，连接被长期占用
根本原因：标准 sql.DB 没有“慢连接熔断”能力，它的健康检查仅限于 Ping（且默认不启用），而且 Ping 本身也不带超时上下文。
用 context.WithTimeout 包裹每次查询是最直接的拦截点
慢连接无法靠连接池“自动识别”，但你可以让每次使用都自带超时，把“慢”变成“失败”，再由上层重试或降级。这是最轻量、最可控的做法。
关键不是改池子，而是改用法：
- 所有
Query、Exec、QueryRow都必须传入带超时的context.Context - 不要依赖
db.SetConnMaxLifetime或SetMaxIdleConns来解决慢问题——它们管的是连接生命周期，不是单次操作耗时 - 超时值要区分场景：
readtimeout（查缓存/配置）设为 100ms，writetimeout（下单/扣减）设为 800ms，避免一刀切
示例：
ctx, cancel := context.WithTimeout(context.Background(), 300*time.Millisecond)
defer cancel()
err := db.QueryRowContext(ctx, "SELECT id FROM users WHERE name = ?", name).Scan(&id)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
// 记录慢查询指标，或触发告警
log.Warn("slow query detected")
}
return err
}
go-mysql-driver 的 timeout 参数只是连接建立阶段有效
很多人误以为在 DSN 里加 timeout=300ms 就能控制查询超时，其实它只作用于 TCP 连接建立和 TLS 握手阶段，对后续的 SQL 执行完全无效。
DSN 中真正影响运行时行为的参数只有几个：
-
readTimeout：控制单次 网络读操作 超时（如接收一个 packet），不是整条 SQL -
writeTimeout：同理，只管单次写包，不是整条语句发送完成 -
timeout：仅用于 dial，和慢查询无关
这两个 timeout 默认是 0（禁用），一旦启用，可能意外中断大结果集的流式读取（比如 Rows.Next()），反而引发更多错误。所以更推荐统一走 context 控制，而不是依赖驱动层 timeout。
自定义中间件 + 连接包装器可实现“慢连接标记+隔离”
如果业务对慢连接有强感知需求（比如想统计哪些连接持续变慢、或临时把它移出调度），可以包装 *sql.Conn，记录每次使用耗时，并在归还前判断是否“过慢”：
- 给每个连接附加一个原子计数器，统计最近 N 次平均耗时
- 归还时若平均 > 阈值，不放回空闲队列，而是丢弃（触发重建）
- 注意：不能直接 Close，要用
driver.Conn.Close避免破坏池状态
这个方案复杂度高，且容易误判（比如一次慢是因数据量突增，不是连接本身问题）。生产环境建议优先用 context + 指标监控组合，而非试图“修复慢连接”——连接只是通道，慢的根源永远在 SQL、索引、锁或网络。
真正容易被忽略的一点：很多团队花大量时间调 maxOpen 和 maxIdle，却从不在应用层对单次 DB 操作设超时。慢连接从来不是池子的问题，而是缺乏边界控制的表现。
