优化sql/driver Rows接口Next方法的大量堆分配性能瓶颈

实现sql/driver包的Rows接口时，处理超大查询结果集时，Next(dest []Value)方法的堆分配成为明显性能瓶颈。通过测试代码验证发现，切片赋值操作v = b[5:11]会在堆上分配切片头，导致runtime.mallocgc占用大量CPU时间，单轮测试执行时间达4.154244695s。

测试代码：

b := binary.LittleEndian.AppendUint32(nil, 0)
b = binary.LittleEndian.AppendUint16(b, 5)
b = append(b, "hello"...)
t := time.Now()
var v driver.Value
for i := 0; i < 100000000; i++ {
    v = b[5:11]
}
_ = v
fmt.Println(time.Since(t))

解决方案 #

• 复用切片对象，直接修改切片头
  预先创建一个固定的切片对象，每次通过unsafe包直接修改其底层指针、长度和容量，避免每次创建新切片导致的堆分配：

  import "unsafe"
  import "reflect"
  
  // 预先初始化复用的切片
  var reuseSlice []byte
  
  // 在循环中复用
  hdr := (*reflect.SliceHeader)(unsafe.Pointer(&reuseSlice))
  hdr.Data = uintptr(unsafe.Pointer(&b[5])) // 指向目标字节的起始地址
  hdr.Len = 6                              // 切片长度
  hdr.Cap = 6                              // 切片容量
  v = reuseSlice
  

  这种方式完全复用同一个切片对象，不会产生新的堆分配。

• 跳过driver.Value接口，直接使用具体类型
  如果明确返回值的类型（比如[]byte），直接用具体类型变量接收结果，避免接口赋值带来的切片头逃逸。接口存储切片类型值时，切片头会被分配到堆上，直接使用具体类型可以避免这个问题。

• 用sync.Pool缓存切片对象
  如果无法复用单个切片，可使用sync.Pool缓存一批切片对象，减少频繁malloc和GC的开销：

  import "sync"
  
  var slicePool = sync.Pool{
      New: func() interface{} {
          return make([]byte, 6) // 预先创建对应长度的切片
      },
  }
  
  // 在循环中
  s := slicePool.Get().([]byte)
  copy(s, b[5:11]) // 复制数据到缓存切片
  v = s
  slicePool.Put(s) // 使用完毕放回池
  

  注意：如果直接引用底层数组的切片放回池，后续修改可能影响已使用的切片，因此建议使用copy复制数据，或者确保底层数组不会被修改。

• 转换为字符串（适用字符串场景）
  如果返回的是字符串类型数据，使用Go 1.20+提供的unsafe.String直接将字节数组转为字符串，无需分配内存：

  v = unsafe.String(&b[5], 6)
  

  字符串不可变，直接复用底层字节数组，赋值给driver.Value时不会产生切片头的堆分配。

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