连接池超时的典型错误现象是context deadline exceeded或i/o timeout，而非数据库宕机；根本原因多为连接池参数配置不当，如SetMaxOpenConns超过数据库max_connections、未设SetConnMaxIdleTime导致空闲连接被DB侧回收后复用失败，或事务未闭环释放连接。
连接池超时的典型错误现象
你看到的 context deadline exceeded 或 dial tcp: i/o timeout，大概率不是数据库挂了，而是连接池没配好。更隐蔽的是 sql: database is closed —— 这往往发生在连接被空闲超时回收后，又被未检查状态的 goroutine 拿去复用。
MySQL连接池关键参数怎么设
Go 的 *sql.DB 自带连接池，但默认值完全不能用于生产：
-
SetMaxIdleConns(10)：空闲连接上限。设太小（比如 2）会导致频繁创建/销毁连接；设太大（比如 200）又浪费 DB 资源。建议设为预估平均并发数的 20–30%，例如 QPS 500、平均响应 200ms → 并发约 100 →MaxIdleConns设 20–30 -
SetMaxOpenConns(100)：最大打开连接数。必须 ≤ 数据库服务器的max_connections（如 MySQL 默认 151），否则新请求会卡在连接获取阶段，报context deadline exceeded -
SetConnMaxLifetime(30 * time.Minute)：强制连接过期时间。不设的话，长连接可能因网络中断或 DB 主从切换失效，但池子还一直留着它 -
SetConnMaxIdleTime(5 * time.Minute)：空闲连接回收时间。比IdleTimeout更精准，推荐设为略小于 DB 的wait_timeout（如 MySQL 默认 8 小时 → 这里设 7h）
Redis连接池超时配置陷阱
Gin 项目常用 github.com/go-redis/redis/v8，它的连接池行为和 *sql.DB 不同：
- 没有
MaxIdle概念，只有MinIdleConns和MaxConnAge—— 别照搬旧版 redis-go 的MaxIdle配置 -
MinIdleConns是保底空闲数，设 0 表示“按需创建”，但高并发下会抖动；建议设为 5–10 -
MaxConnAge必须设（如30 * time.Minute），否则连接长期存活，遇到 Redis 节点重启或连接闪断后无法自动重建 - 别依赖
PoolSize控制总连接数：它只是“最多允许多少连接同时活跃”，真正限制资源的是 Redis 服务端的maxclients，务必对齐
超时错误该不该重试
不是所有超时都适合重试：
-
context.DeadlineExceeded：说明你的业务逻辑或上游调用耗时太久，重试只会雪上加霜。应先查 handler 是否有阻塞操作（如未设 timeout 的http.Get、同步文件读写） -
io timeout或connection refused：可能是网络抖动或 DB 瞬间不可达，可对幂等操作（如 GET 查询）做 1 次重试，但必须带 jitter 避免打爆下游 - 永远不要对写操作（INSERT/UPDATE）盲目重试——除非你确认是纯网络层失败且已实现幂等性校验
连接池本身不负责重试，那是业务层或客户端库的事。把超时归因于“连接池没配好”，常常掩盖了真正的瓶颈：慢查询、锁等待、或没给 context 传入合理 deadline。
