使用GORM调用Find方法出现database/sql.convertAssignRows内存泄漏问题

针对你遇到的内存泄漏问题，结合代码分析，给出以下排查和修复方案：

• 修正Raw+Find的错误用法
  GORM中Raw()执行原生SQL后，不应再调用Find()做结果绑定，Find()是用于GORM链式查询的方法，和Raw()混用会导致内部row对象无法正确释放，进而触发内存泄漏。正确做法是直接用Scan()映射结果：

  func (mp *message) ListMessage(ctx context.Context, ci *ClientInfo) ([]Message, error) {
      var mss []MessageSource
      err := mp.db.WithContext(ctx).Raw(sql).Scan(&mss).Error
      if err != nil {
          return nil, err
      }
      return mss, nil
  }
  

• 检查上下文生命周期
  确保传入的ctx会在请求结束或任务完成时被正确取消（比如上游调用时使用context.WithCancel并在合适时机触发cancel）。如果上下文长期未被回收，GORM持有的数据库连接、row资源会一直占用内存。

• 优化数据库连接池配置
  不合理的连接池参数可能导致连接堆积，间接引发内存泄漏。调整连接池参数，确保闲置连接能及时回收：

  sqlDB, err := mp.db.DB()
  if err != nil {
      panic(err)
  }
  sqlDB.SetMaxOpenConns(100)   // 最大打开连接数
  sqlDB.SetMaxIdleConns(20)    // 最大闲置连接数
  sqlDB.SetConnMaxLifetime(time.Hour) // 连接最大存活时间
  

• 校验结构体与SQL列的匹配性
  如果MessageSource的字段与SQL查询返回的列不匹配（包括列名、类型），database/sql.convertAssignRows在映射过程中会产生未被回收的临时对象。检查SQL查询列和结构体字段的对应关系，确保列名与字段名（或gorm标签）完全匹配。

• 大结果集添加分页逻辑
  如果SQL返回大量数据，一次性加载到内存会导致内存占用飙升，类似内存泄漏的表现。添加分页分段加载数据：

  // 示例：按页码分页，page为当前页，pageSize为每页条数
  err := mp.db.WithContext(ctx).Raw(sql).Offset((page-1)*pageSize).Limit(pageSize).Scan(&mss).Error
  

内容的提问来源于stack exchange，提问作者new2niu