Go database/sql.RawBytes 怎样避免复制查询结果

如果 Go 服务批量读取二进制列，直接把结果扫描到 []byte 会得到一份由调用方持有的副本；扫描到 *sql.RawBytes 可以避开这次复制，但换来更严格的生命周期约束。选择的关键不是“哪个类型更快”，而是当前行数据是否只在本轮消费，还是要跨行保存。

核心结论：短暂处理当前行时可以使用 sql.RawBytes；只要数据要放进结果集合、异步任务或下一轮循环，就必须显式复制。RawBytes 在下一次 Rows.Next、Rows.Scan 或 Rows.Close 后不再保证有效。

本文只讨论标准库 database/sql 的扫描语义、所有权和资源边界，不绑定某个具体数据库驱动。

先区分 []byte 与 RawBytes 的所有权

Rows.Scan 对 *[]byte 会保存一份调用方拥有的副本，因此可以在循环外继续使用。*sql.RawBytes 则是对驱动内存的借用视图：它适合在当前行中立即解析、计算摘要或写入一个已经准备好的输出缓冲区，但不能默认它能跨下一次扫描继续存在。

这个差异可以压缩成一张判断表：

按当前行范围消费 RawBytes

最安全的使用方式是让 RawBytes 的作用域停留在一次 Scan 与本轮业务处理之间。下面的示例只把当前行内容转成十六进制摘要字符串；字符串已经是新的值，不会把借用切片带到下一轮循环。

package main

import (
	"database/sql"
	"encoding/hex"
	"fmt"
)

func consumeRows(rows *sql.Rows) error {
	defer rows.Close()

	for rows.Next() {
		var raw sql.RawBytes
		// RawBytes 只在本轮 Scan 与业务处理期间借用驱动内存。
		if err := rows.Scan(&raw); err != nil {
			// Scan 失败时立即返回，避免继续使用不完整的数据。
			return fmt.Errorf("扫描二进制列: %w", err)
		}

		// EncodeToString 返回新的 string，可安全交给日志或当前行结果。
		digest := hex.EncodeToString(raw)
		fmt.Println(digest)
	}
	// Next 返回 false 可能是自然结束，也可能是迭代错误。
	if err := rows.Err(); err != nil {
		return fmt.Errorf("遍历查询结果: %w", err)
	}
	return nil
}

这里的重点是“消费结果”，不是把 raw 放进共享切片。即使当前驱动暂时没有复用底层缓冲区，也不能据此放宽代码约束，因为 RawBytes 的契约已经把所有权交给驱动。

需要跨行保存时显式复制

如果业务要把每行字节放入缓存、结果集合、异步消息或闭包，先复制再保存。复制动作应该紧挨着 Scan，这样一眼就能看出借用数据在哪里转成了调用方拥有的数据。

func collectPayloads(rows *sql.Rows) ([][]byte, error) {
	defer rows.Close()
	var payloads [][]byte

	for rows.Next() {
		var raw sql.RawBytes
		// 先取得当前行的借用视图，再决定是否跨行保存。
		if err := rows.Scan(&raw); err != nil {
			return nil, fmt.Errorf("扫描 payload: %w", err)
		}

		// append 到 nil 切片会创建调用方拥有的独立副本。
		owned := append([]byte(nil), raw...)
		payloads = append(payloads, owned)
	}
	if err := rows.Err(); err != nil {
		return nil, fmt.Errorf("读取 payload: %w", err)
	}
	return payloads, nil
}

如果项目使用的 Go 版本提供 bytes.Clone，也可以写成 owned := bytes.Clone(raw)。无论采用哪种写法，关键都是复制后的切片不再依赖驱动内存。

按负载约束选择方案

可以把决策拆成三个约束：数据是否只在当前行使用、是否必须跨行持有、查询结束时是否完整处理错误。这样做比在所有查询中机械替换成 RawBytes 更稳妥。

• 短生命周期：当前行立即解析、编码或写出，使用 RawBytes 可以减少一次复制，但不要把切片交给延迟执行的 goroutine。
• 跨行持有：需要结果集合、缓存或异步处理时，使用 []byte 或复制后的切片，优先保证所有权清晰。
• 错误与资源：无论选择哪种类型，都要检查 Scan、循环后的 Rows.Err，并确保 Rows.Close 执行。

常见误区与落地清单

误区一：把 RawBytes 当成零成本永久缓存。它只是避免了当前扫描的复制，不改变驱动拥有底层内存的事实。误区二：只检查 Next，不检查 Rows.Err。Next 返回 false 既可能是正常结束，也可能是迭代错误。误区三：为了少一次复制，把所有字段都改成 RawBytes。只有在当前行内消费的字段才适合这样做。

落地时可以遵循一条简单规则：先按默认的 []byte 写清楚所有权；确认复制确实是热点后，再把局部当前行路径改为 RawBytes，并把跨行分支保留为显式复制。这样性能优化和生命周期边界都能被代码直接表达。

相关问题

RawBytes 和 []byte 的主要区别是什么？

[]byte 目标通常由 database/sql 复制并交给调用方持有；RawBytes 借用驱动内存，生命周期短，但可以避免这次复制。

为什么 RawBytes 不能放进异步任务？

异步任务可能在下一次 Next、Scan 或 Close 之后才执行，此时借用内存已经超出契约。提交任务前应复制成独立切片或字符串。

只要想减少分配就应该用 RawBytes 吗？

不应该。先确认数据确实只在当前行消费，并权衡代码可读性、驱动行为和错误处理；需要长期保存时，显式复制更可靠。