Go 标准库 database/sql 中的 *sql.Rows 不提供直接获取行数的方法，必须通过遍历（Next）或改写 SQL（如 COUNT(*)）实现；本文详解可行方案、性能权衡及 ORM 场景下的最佳实践。
go 标准库 database/sql 中的 `*sql.rows` 不提供直接获取行数的方法，必须通过遍历（next）或改写 sql（如 count(*)）实现；本文详解可行方案、性能权衡及 orm 场景下的最佳实践。
在 Go 的数据库操作中，*sql.Rows 是一个流式、只读、单向迭代器，其设计哲学强调内存效率与延迟加载——数据仅在调用 Next() 时按需从底层驱动提取，并立即解码。正因如此，sql.Rows 接口刻意不暴露行数（Count/Length）方法，既避免驱动层缓存全部结果（违背流式语义），也规避了跨数据库行为不一致的风险（例如某些驱动可能无法预知结果集大小）。
✅ 可行方案对比分析
| 方案 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 双遍历（两次 Next） | 先遍历计数，再重置并遍历取值 | 无需修改 SQL，完全兼容任意驱动 | 需两次网络/IO 轮次，内存无额外开销但耗时翻倍 | 小结果集（ |
| *COUNT() 预查询** | 执行 SELECT COUNT(*) FROM (...) 子查询或独立 COUNT 查询 | 结果精确、一次获取总数、便于分页/进度反馈 | 额外一次查询，存在幻读风险（并发增删导致计数与实际结果不一致） | 需提前知道总数（如分页控件）、大数据集、ORM 框架层封装 |
| *SELECT + COUNT() 同查** | SELECT col1, col2, ..., (SELECT COUNT(*) FROM ...) AS total | 单次查询获取数据与总数 | SQL 复杂度上升，部分数据库不支持子查询位置灵活，ORM 解析难度高 | 对一致性要求极高且能接受 SQL 改写的小型项目 |
⚠️ 注意：rows.Err() 必须在循环结束后检查，否则可能掩盖 Next() 过程中的错误（如类型转换失败、连接中断）。
? 示例：安全的双遍历实现（推荐用于小数据集）
func countAndScan(db *sql.DB, query string, args ...any) (int, []map[string]interface{}, error) {
rows, err := db.Query(query, args...)
if err != nil {
return 0, nil, err
}
defer rows.Close()
// 第一遍：统计行数
count := 0
for rows.Next() {
count++
}
if err = rows.Err(); err != nil {
return 0, nil, err
}
// 重新执行查询（无法重置 rows）
rows, err = db.Query(query, args...)
if err != nil {
return 0, nil, err
}
defer rows.Close()
// 第二遍：扫描数据（此处以 map 形式示意）
columns, _ := rows.Columns()
var results []map[string]interface{}
for rows.Next() {
values := make([]interface{}, len(columns))
valuePtrs := make([]interface{}, len(columns))
for i := range columns {
valuePtrs[i] = &values[i]
}
if err := rows.Scan(valuePtrs...); err != nil {
return 0, nil, err
}
row := make(map[string]interface{})
for i, col := range columns {
row[col] = values[i]
}
results = append(results, row)
}
return count, results, rows.Err()
}
? ORM 开发建议
作为 ORM 作者，应避免强行抽象“行数获取”为通用接口。更合理的做法是：
- 提供 Count() 方法，内部生成并执行 SELECT COUNT(*) —— 显式语义，开发者清楚代价；
- 在 FindAll() 等方法中默认不返回总数，仅当用户显式调用 .WithCount() 时才追加 COUNT 查询；
- 文档明确说明：Rows 本身不可知长度，任何“获取总数”行为均引入额外查询或遍历开销。
✅ 总结
没有银弹：*sql.Rows 的本质决定了它无法零成本获知行数。选择方案应基于实际约束——
? 若结果集小且逻辑简单 → 接受双遍历，代码简洁、无 SQL 侵入；
? 若需精确总数或数据量大 → 使用 COUNT(*) 预查询，但需在业务层处理幻读；
? 切勿尝试反射或驱动私有字段——破坏接口契约，丧失可移植性。
最终，尊重 sql.Rows 的流式设计，是写出健壮、高效 Go 数据层代码的前提。
