微服务数据库问题八成源于连接管理、错误处理和查询方式不匹配其生命周期与并发模型：需显式Ping验证连接、合理配置连接池参数、严格检查QueryRow/rows.Next错误、复用预编译语句。
Go微服务里数据库操作慢、连接耗尽、查询超时，八成不是SQL写得差，而是连接管理、错误处理和查询方式没对齐微服务的生命周期和并发模型。
sql.Open 不等于数据库连上了
很多人调完 sql.Open 就直接执行查询，结果在第一次 Query 或 Ping 时才暴露网络不通、认证失败等问题。这在微服务启动探针或健康检查里会直接导致服务反复重启。
- 必须显式调用
db.Ping()验证连接可用性，且应放在服务初始化阶段（比如initDB()函数里） -
sql.Open只是创建连接池对象，不建任何物理连接；db.Ping()才真正从池里取一个连接做握手 - 若
Ping()失败，别重试 5 次再 panic —— 应快速失败并退出进程，让 Kubernetes 之类调度器重新拉起
连接池参数没调对，压测就崩
默认配置在微服务场景下基本不可用：MaxOpenConns=0（无上限）、MaxIdleConns=2（太小），高并发下要么连接爆炸，要么频繁新建销毁连接。
-
SetMaxOpenConns(20)：按后端数据库最大连接数的 70% 设（如 MySQL 默认 151，则设 100 左右） -
SetMaxIdleConns(5)：避免空闲连接长期占用资源，又不至于每次请求都新建连接 -
SetConnMaxLifetime(5 * time.Minute)：强制更换老连接，防止因中间件（如 ProxySQL、RDS 代理）断连导致的 stale connection 错误 - 注意：不要设
SetConnMaxIdleTime过短（如 30s），否则空闲连接刚建好就被回收，反而加重开销
QueryRow 和 rows.Next 忘记检查 err，线上静默失败
最隐蔽的 bug 是查不到数据就当“没这事”，或者迭代中途出错却没感知 —— 表现为接口返回空、前端报 500、日志里没错误痕迹。
- 用
QueryRow().Scan()时，必须区分sql.ErrNoRows和其他错误：if err == sql.ErrNoRows是业务正常路径，其余 err 才该记录告警 - 用
rows.Next()遍历时，循环结束后一定要检查rows.Err()，否则磁盘 I/O 错误、网络中断等底层问题会被吞掉 - 别依赖
defer rows.Close()来掩盖错误 —— 它只释放资源，不报告查询过程是否完整 - 批量查询建议用
FindInBatches（GORM）或分页LIMIT/OFFSET，避免单次加载上万行撑爆内存
Prepared Statement 开启了但没复用
开了 PrepareStmt: true 却还在循环里反复调 db.Query("SELECT ... WHERE id = ?", id)，等于白配 —— 每次都走一次 prepare + execute，性能反不如普通查询。
- 预编译语句真正生效的前提是 SQL 模板固定、仅参数变化；动态拼接表名/字段名的语句无法复用
- 高频查询（如用户登录校验、订单状态查询）应提取为独立函数，内部复用
*sql.Stmt实例 - 注意：
stmt.Close()会从连接池中移除该预编译语句，除非确定不再使用，否则不要随便关 - GORM 的
PrepareStmt对First、Create等方法自动生效，但自定义原生 SQL 查询仍需手动db.Raw().Scan()并确保复用
微服务里数据库操作的复杂点不在语法，而在它横跨了连接生命周期、goroutine 调度、错误传播链三个维度 —— 任何一个环节漏掉上下文取消、资源关闭或错误分类，都会变成压测时突然爆发的雪崩点。
