Go database/sql Result.RowsAffected 不支持时怎么办

我在处理批量更新接口时，最容易误读的一项信息就是 Result.RowsAffected()：有的驱动能返回影响行数，有的驱动会在读取这个值时返回错误。这个错误不等于 SQL 没有执行成功，更不能直接把它改写成“影响 0 行”。

官方地址：https://pkg.go.dev/database/sql@go1.27.3#Result

正确的处理顺序是：先判断 ExecContext 是否执行失败，再单独读取 RowsAffected。只有第二步的 err 为空时，affected 才能作为可信计数；如果驱动不支持，就把它记录为“未知”，不要伪装成零。

先把 Result 看成执行回执

database/sql 的 Result 只是一次写操作的执行回执，包含 LastInsertId 和 RowsAffected 两个可选能力。官方文档明确说明，并不是每个数据库或驱动都支持 RowsAffected。因此，执行成功与“能否读取影响行数”是两个不同层次。

从数据生命周期看，一条更新语句先经过 ExecContext，得到 sql.Result；随后应用才向回执询问 RowsAffected。最后这个数值是否参与业务判断，还要由应用策略决定。图中只表达这些对象之间的静态关系，不是某次真实运行的截图。

把执行错误和读取错误分开

代码里不要只写一层 if err != nil 就结束。第一层对应 SQL 本身没有完成，例如连接、语法或参数问题；第二层对应 SQL 已经得到一个回执，但驱动无法提供影响行数。两层错误的处理动作不同，尤其不能因为第二层报错就自动重放原语句。

package main

import (
    "context"
    "database/sql"
    "fmt"
)

// updateUserStatus 只把影响行数作为可选观测信息返回。
func updateUserStatus(ctx context.Context, db *sql.DB, id int64) (int64, error) {
    // ExecContext 的错误表示写操作本身没有得到可用回执。
    result, err := db.ExecContext(ctx,
        "UPDATE users SET status = ? WHERE id = ?", "active", id)
    if err != nil {
        return 0, fmt.Errorf("执行更新失败: %w", err)
    }

    // RowsAffected 可能由驱动返回“不支持”错误，不能忽略第二个返回值。
    affected, err := result.RowsAffected()
    if err != nil {
        return 0, fmt.Errorf("读取影响行数失败: %w", err)
    }
    return affected, nil
}

上面的函数选择把“读取不到影响行数”作为错误交给上层。若业务允许降级，也可以把返回类型改成 (int64, bool, error)，用布尔值表达计数是否可信。无论哪种设计，都要保留这两个层次，别用一个数字把它们压平。

把未知结果与 0 行分开

最危险的误判是把 RowsAffected 返回错误当成 0。这两种状态的含义完全不同：

这里的“未知”是一个真实业务状态。比如接口只需要告诉调用方“请求已受理”，就不必把驱动能力缺失升级为整个操作失败；但如果业务必须确认恰好更新了一行，就应该明确返回不可确认，而不是继续往下走。

我会保留的三个工程边界

第一，RowsAffected 的错误不是“更新失败”的同义词。是否失败要看 ExecContext 的返回值，不能用第二次读取的能力判断替代第一次执行结果。

第二，不要为了拿到一个数字而重试原 SQL。影响行数读取失败发生在执行回执阶段，重试可能造成重复写入；是否重试应由明确的幂等键、事务语义和业务策略决定，而不是由 RowsAffected 的错误触发。

第三，不要把驱动差异藏在基础库里。基础库可以返回“计数可信/未知”的状态，上层再决定是写审计日志、返回弱化提示，还是阻断需要精确计数的流程。这样未来更换驱动时，未知状态不会悄悄变成错误的 0。

常见问题

RowsAffected 返回 0 就是没有更新到数据吗？

只有在第二个返回值为 nil 时，0 才表示驱动报告没有受影响的行。若同时有错误，计数不可信，应按未知处理。

能不能直接忽略 RowsAffected 的错误？

如果业务完全不依赖影响行数，可以记录后降级；但不建议静默丢弃。至少要让日志、指标或返回状态保留“驱动不支持读取计数”这一事实。

总结：Result.RowsAffected() 是可选能力，不是 SQL 成功的证明。先处理执行结果，再处理计数能力；把可信的 0 和未知分开，才能避免误报和重复写入。