微服务中 database/sql 同步查库易致雪崩，因 RT 累加、goroutine 积压、连接池耗尽；需下沉数据获取、启用批处理+缓存防 N+1，调优连接池参数，并按场景选 pgx 或手写 SQL。
为什么 database/sql 直接查库在微服务里容易拖垮响应？
微服务中单次请求常需聚合多个数据源（用户服务、订单服务、库存服务），若每个下游都用 database/sql 同步阻塞查询，RT 累加、goroutine 积压、DB 连接池迅速耗尽——这不是慢，是雪崩前兆。
真正关键的不是“怎么查”，而是“谁来查、何时查、查多少”：
- 避免在 HTTP handler 中直接调
db.QueryRow；把数据获取下沉到 domain 层或单独的DataLoader组件 - 对同一请求内多次请求相同 ID 的数据（如 10 个订单查同一个用户），必须启用批处理 + 缓存，否则 N+1 查询立刻显现
-
sql.DB的SetMaxOpenConns和SetMaxIdleConns必须按服务 QPS 调整，Gin 默认启动 10k goroutine，但 DB 连接池设成 5 就注定排队
用 go-graph-gophers/dataloader 消除 N+1 查询真的够用吗？
它能合并同 batch 内的 key（比如 7 个 user_id=123 请求自动聚合成一次 SELECT * FROM users WHERE id IN (123)），但有硬伤：
- 只适用于「单表主键查询」场景，无法处理
JOIN或复杂 where 条件（例如WHERE status = 'paid' AND created_at > NOW() - INTERVAL '7 days'） - batch 函数必须返回
[]*User，不能返回map[int]*User，否则空值位置错位会导致 panic - 默认 batch timeout 是 1ms，高并发下易触发过早合并，反而增加 DB 压力；建议设为
5ms并配合WithWait控制延迟
示例关键配置：
