性能调优：连接池、复用与常见瓶颈

面试问法：GoFrame 项目 QPS 上不去，你会从哪些点排查？连接池怎么配？ 一句话结论：先关 debug、设超时、看慢 SQL，通常能解决八成问题；再往下是连接池参数、对象/连接复用与 N+1 查询。框架的数据库与 Redis 均自带连接池，配置写在对应配置节点即可，性能分析用官方 pprof 能力（s.EnablePProf()）。

数据库连接池

database:
  default:
    link: "mysql:root:pass@tcp(127.0.0.1:3306)/db?loc=Local&parseTime=true"
    debug: false            # 生产务必关闭：SQL 全量打印开销大
    maxIdle: 10             # 空闲连接上限
    maxOpen: 100            # 最大打开连接数（别无限大，超库上限只会排队）
    maxIdleTime: "60s"      # 空闲回收时间
    maxLifeTime: "30m"      # 连接最长存活，小于 DB/中间代理的回收周期
    queryTimeout: "5s"      # 查询超时，防慢 SQL 拖垮协程

Redis 配置节点同理带池化参数（maxActive/maxIdle/idleTimeout/maxConnLifetime 及各类超时），低频操作多时适当调大 maxIdle 减少建连。

复用意识与常见瓶颈

• 复用单例：g.DB()、g.Redis()、g.Cache() 长期复用，不要每次请求新建客户端。
• N+1 查询是头号杀手：列表接口里循环查详情 → 先查主表再 WhereIn 批量取关联数据。
• 慢 SQL 无感知：开 ORM 日志定期看慢查询，稳定几十毫秒以上的 SQL 优先优化索引。
• 缓存穿透/雪崩：热点数据用 gcache/Redis 缓存 + 合理过期 + 空值保护。
• goroutine 泄漏：手写 go func() 无退出条件、ctx 不传导致内部超时失效，是内存上涨常见原因，优先用受控协程/池。

// 反例：循环内逐条查（N+1）
for _, id := range ids {
    u, _ := dao.User.Ctx(ctx).Where("id", id).One()
}
// 正例：一次批量查询
list, err := dao.User.Ctx(ctx).WhereIn("id", ids).All()

排查顺序建议

1. 确认生产 debug: false、queryTimeout 已设。
2. 慢查询日志 → 索引与 SQL 重构。
3. pprof/火焰图定位 CPU、内存热点（官方提供 s.EnablePProf() 能力，细节以官方文档为准）。
4. 检查连接池监控（活跃/空闲连接、等待时长）后再调参——一次只改一个变量并压测。

常见追问

• 追问：maxOpen 是不是越大越好？——不是；超过数据库并发上限只会让请求在池里排队，参数要与库规格、压测结果匹配。
• 追问：为什么 debug: true 会明显掉 QPS？——每条 SQL 都打印语句与调用堆栈，日志 IO 成为热点路径瓶颈。

记忆点

• 先关 debug、设超时、灭 N+1；池参数是权衡值，靠监控与压测迭代。