Go 1.27 数据库驱动如何少做一次中转：RowsColumnScanner 直接写入目标值

数据库驱动处理宽表或大批量结果集时，真正值得盯住的往往不是 SQL 本身，而是每一列从驱动内部表示落到 rows.Scan 目标地址之间有没有多余中转。Go 1.27 新增 driver.RowsColumnScanner，允许驱动把“推进当前行”和“写入某一列”分开实现。它提供的是一条可优化的接口边界，并不承诺所有驱动都会自动变快；是否减少分配，仍要看驱动怎样解码列值。

传统扫描边界为何会出现中转层

旧接口要求 Rows.Next 把当前行填进一个 []driver.Value。随后 database/sql 再由 Rows.Scan 把这些通用值转换到用户目标地址。这个设计兼容性很好，但驱动即使已经知道数据库原生类型与用户目标类型，也必须先交付通用值。

type Rows interface {
    Columns() []string
    Close() error
    Next(dest []driver.Value) error
}

// database/sql 再把通用值转换到调用方目标地址。
err := rows.Scan(&id, &createdAt, &payload)

这里不能直接得出“中转一定很慢”。如果驱动本来就以 driver.Value 保存一行，额外成本可能很低；如果驱动内部拥有更精确的二进制表示，却先转换成字符串或字节切片，再由 Rows.Scan 转一次，才可能出现可见的分配与复制。

RowsColumnScanner 把列转换交回驱动

Go 1.27 的新接口仍然包含 Rows，因此驱动要继续实现 Columns、Close 和 Next。新增的 NextRow 只负责推进当前行，ScanColumn 则接收列序号与用户目标地址。只要返回的 Rows 实现了该接口，Go 1.27 的 database/sql 就不会调用 Rows.Next。

type RowsColumnScanner interface {
    driver.Rows
    NextRow() error
    ScanColumn(ctx driver.ScanContext, index int, dest any) error
}

ScanContext 携带当前查询相关状态。驱动若使用标准转换逻辑，必须把收到的上下文原样传给 sql.ConvertAssign；不能在方法里随手换成空上下文。这个函数主要供驱动实现者使用，普通业务代码继续调用 rows.Scan 即可。

兼容实现要同时保留新旧两条接口

一个现实的驱动通常还要支持 Go 1.26 或更早版本，所以 Next 不能立即删除。可以让新旧入口共享底层“读取一行”能力，但不要让 NextRow 和 Next 各自再读一次网络数据。

func (r *rows) NextRow() error {
    // 只推进一行，并保留驱动自己的原始列表示。
    return r.readCurrentRow()
}

func (r *rows) ScanColumn(ctx driver.ScanContext, i int, dest any) error {
    col, err := r.currentColumn(i)
    if err != nil {
        return err
    }

    // 已有原生快速转换时直接写入 dest；
    // 其他类型回落到标准转换规则。
    if ok, err := col.assignNative(dest); ok {
        return err
    }
    return sql.ConvertAssign(ctx, dest, col.DriverValue())
}

func (r *rows) Next(dest []driver.Value) error {
    if err := r.NextRow(); err != nil {
        return err
    }
    return r.copyAsDriverValues(dest)
}

这段骨架的关键不是方法名，而是职责边界：NextRow 只移动游标，ScanColumn 只处理当前行的一列，旧 Next 只服务兼容路径。驱动自己的 assignNative、DriverValue 和行缓冲结构需要按协议与数据类型实现。

性能基准要比较三组指标

不要拿一条整数查询就宣布新接口更快。比较时应固定数据库版本、连接参数、结果集行数、列数和目标类型，并覆盖字符串、时间、可空值、二进制列等真实负载。至少记录下面三组指标。

func BenchmarkScanRows(b *testing.B) {
    b.ReportAllocs()
    for i := 0; i 

如果结果只减少了函数层级，却没有降低分配，说明驱动仍在 ScanColumn 内构造通用值；如果分配下降但错误语义变化，优化也不能上线。真正可接受的结果是：常用类型收益稳定，边界类型保持 Rows.Scan 既有转换语义。

常见误区与上线检查

• 不要在 NextRow 和 ScanColumn 中重复读取网络数据，后者只处理当前行。
• 不要假设 ScanColumn 一定零分配；回落到通用值时仍可能产生临时对象。
• 不要删除 Next，接口嵌入了 Rows，而较早工具链仍需要旧路径。
• 不要忽略用户自定义的 sql.Scanner，标准转换与错误包装应保持兼容。
• 不要只测单列整数；宽表、NULL、时间与大字节列更容易暴露真实差异。

相关问题

业务代码需要改成调用 ScanColumn 吗？

不需要。业务层仍调用 rows.Scan，是否走新路径由 database/sql 根据驱动返回的 Rows 类型判断。

实现 RowsColumnScanner 后 Next 还会被调用吗？

Go 1.27 不会调用它，但接口仍要求存在，而且驱动可能需要用它兼容更早 Go 版本。

所有列都必须自己实现原生转换吗？

不必。适合优化的常用类型可走驱动原生路径，其余类型可通过 sql.ConvertAssign 复用标准转换规则。

怎样证明这项改动值得合并？

用相同数据集比较耗时与分配，同时跑完整扫描兼容测试。只有性能收益和转换语义都稳定，才适合默认启用。

结语

RowsColumnScanner 的价值，是让数据库驱动不再被强制固定在“先交付通用值、再由标准库转换”的单一路径。它给驱动作者提供了更靠近协议解码层的优化位置，也把正确性责任带回驱动内部。先保留兼容路径，再用真实结果集证明分配和耗时收益，比单纯实现新接口更重要。