每个*sql.DB实例必须独立配置连接池参数，因其连接池相互隔离，共用参数会导致慢查询拖垮所有库；需为各库显式设置SetMaxOpenConns等参数，并分别调用Ping()验证连通性，定期监控db.Stats()以动态调优。
多个*sql.DB实例必须独立配置连接池参数
共用同一套连接池参数（比如只对第一个db1调用SetMaxOpenConns(100)，却没设db2）会导致其中一个库的慢查询或长事务直接拖垮所有数据库操作。Go 的 *sql.DB 是**每个实例独立维护连接池**的，不会自动继承或共享配置。
常见错误现象：db1 执行一个耗时 5 秒的报表查询，db2（用户 API 库）的请求开始超时、WaitCount 持续上涨，但日志里查不到 db2 的慢 SQL。
- 每个
*sql.DB实例初始化后，必须立即、显式调用SetMaxOpenConns、SetMaxIdleConns和SetConnMaxLifetime - 不同库用途不同（如主业务库 vs 日志库 vs 分析库），应按实际负载分别设参：API 库建议
SetMaxOpenConns(50)，分析库可设20并配更长SetConnMaxLifetime - 别复用同一个 DSN 配置对象去初始化多个
*sql.DB，除非你确认它们真的该用完全一致的池策略
事务中跨库操作不能靠“自动复用”解决
想在一个 HTTP 请求里同时写主库 + 写日志库，并认为“反正都是 *sql.DB，事务能兜住”——这是典型误判。database/sql 不支持跨库事务，tx.Commit() 只作用于当前 *sql.Tx 绑定的那个 *sql.DB 实例。
错误写法：tx1 := db1.Begin(); tx2 := db2.Begin(); ... tx1.Commit(); tx2.Commit() → 若 tx2.Commit() 失败，tx1 已提交，无法回滚。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 跨库写入必须用业务层补偿：先写主库，成功后发消息/写本地 Kafka，由消费者异步写日志库；失败则告警+人工核对
- 若强行用
Session或WithContext包裹多库操作，只是隔离了单库内的连接，不提供原子性保证 - 尤其注意
db1.WithContext(ctx).Transaction()中的ctx超时只约束db1，db2完全不受控
db.Ping() 必须在每个 *sql.DB 初始化后立刻执行
只对主库调 db1.Ping()，忽略 db2 和 db3，上线后某个库首请求必然卡住或报 dial tcp: i/o timeout。因为 sql.Open() 不建真实连接，而 db.Ping() 是唯一能触发并验证底层连通性的同步动作。
- 每个
*sql.DB实例创建后，紧跟着就要做if err := db.Ping(); err != nil，失败必须记录并终止进程（别只打日志继续启动） - 别把
db.Ping()塞进健康检查 endpoint（如/health）——它测的是“此刻能否拨号”，不是连接池实时水位，且频繁调用会干扰空闲连接回收 - 容器环境（K8s）下，Pod 启动时若某库网络未就绪，
Ping()失败应触发重启，而不是降级容忍
监控 db.Stats() 比压测更能暴露连接池问题
只看 QPS 和 P95 延迟，根本发现不了连接池正在泄漏。真正关键的是 db.Stats() 返回的几个字段：它们是连接池真实状态的“体温计”。
-
WaitCount持续上升 →SetMaxOpenConns太小，或有 SQL 执行过慢堵住连接 -
OpenConnections长期接近MaxOpenConns→ 检查是否有rows忘记defer rows.Close()，或事务没Commit/Rollback -
MaxIdleClosed高 →SetMaxIdleConns设太高，低峰期空闲连接被强制关闭，浪费建连开销 - 建议每 30 秒采集一次各库的
db.Stats()，聚合到 Prometheus，告警阈值设为WaitCount > 100或OpenConnections / MaxOpenConns > 0.9
SetMaxOpenConns 可能瞬间变成瓶颈。得靠 db.Stats() 的实时反馈，而不是靠经验或文档里的“推荐值”。 
