Go database/sql ExecContext 怎样判断影响行数为零

在 Go 的 database/sql 里，ExecContext 返回“没有错误”，只说明这次执行没有被驱动报告为失败，并不等于一定修改了数据。判断影响行数要分两层：先检查返回的 error，再在成功后读取 Result.RowsAffected()。如果影响行数为零，还要回到 SQL 的 WHERE 条件和驱动文档，确认它代表未匹配记录、数据未变化，还是驱动不支持该统计。

官方资料：https://pkg.go.dev/database/sql#Result

下面用一个更新用户显示名的场景，把这几个返回值和业务判断拆开。

先把错误和零行结果分开

ExecContext 的返回值可以理解为“结果对象 + 错误”。错误非空时，SQL 可能没有成功执行，此时应先处理错误；错误为空时，才有资格读取 Result 并进一步判断影响行数。零行不是一个 Go 层面的执行错误，而是一个需要结合语句语义解释的结果。

最容易出错的写法，是只判断 err == nil 就返回“更新成功”。例如用户 ID 不存在时，数据库可能正常完成一条没有命中记录的 UPDATE，这个结果往往需要转换成“未找到”，而不是“执行失败”。

用 Result.RowsAffected 读取结果

成功拿到 Result 后调用 RowsAffected。这个方法本身也会返回错误，因为不是所有驱动都能提供影响行数。下面的代码把三种状态分开：SQL 执行失败、无法读取计数、成功读取且影响行数为零。

func updateDisplayName(ctx context.Context, db *sql.DB, id int64, name string) (string, error) {
    // 问号占位符要按实际数据库驱动的参数规则调整。
    const query = `UPDATE users SET display_name = ? WHERE id = ?`

    result, err := db.ExecContext(ctx, query, name, id)
    if err != nil {
        // 这里处理超时、连接错误或 SQL 本身失败，不能把它当成零行。
        return "执行失败", err
    }

    affected, err := result.RowsAffected()
    if err != nil {
        // 驱动不支持影响行数时，保留“已执行但无法计数”的事实。
        return "已执行但无法读取影响行数", err
    }
    if affected == 0 {
        // 零行还要结合 WHERE 和驱动口径解释，不能直接判定为异常。
        return "没有可确认的影响行", nil
    }

    return "已影响记录", nil
}

这里的 context.Context 负责取消和截止时间，Result 负责承载执行结果；两者职责不同。不要因为 RowsAffected 返回零，就反向推断请求一定超时或连接已经失效。

理解零行的数据库语义

零行至少有三种常见解释。第一，WHERE id = ? 没有匹配记录；第二，记录匹配了，但新值与旧值相同，数据库或驱动仍可能报告零；第三，驱动对影响行数的支持有限，读取计数本身就可能失败。database/sql 只定义了结果接口，不替每一种数据库规定“影响”的精确口径。

因此，不能把“零行”简单改写成“数据库报错”。如果业务必须区分“记录不存在”和“值已经是目标值”，通常需要先读取当前值，或在 SQL 条件中加入版本号、旧值等更明确的条件，再按照数据库驱动的说明解释结果。

把判断写进业务决策

更新和删除通常需要不同的产品语义：更新零行可能返回“对象不存在”，删除零行可能被设计成幂等成功；批量写入则可能只关心总影响数。建议把底层结果转换成明确的业务状态，不要让调用方自行猜测 nil 和零值。

复查时按四个问题走一遍：error 是否为空？RowsAffected 是否可读？WHERE 条件是否覆盖了目标记录？当前驱动对“匹配行”和“变更行”的定义是什么？这四个问题能避免把三种状态压缩成一个布尔值。

常见问题

RowsAffected 为零是不是 SQL 执行失败？

不是。执行失败通常通过 ExecContext 返回的 error 表示；零行是在成功执行后对结果数量的进一步解释。

能不能只用 RowsAffected 判断记录是否存在？

不能一概而论。驱动可能按匹配行或实际变化行计数，且不同 SQL、数据库和配置的语义可能不同。需要结合官方驱动文档，必要时设计更明确的查询条件。

记住这条判断链：先处理 error，再读取 RowsAffected，最后用 SQL 条件和驱动口径解释零值。这样既不会把正常的“未命中”误报成系统故障，也不会把无法确认的结果伪装成成功。