Query 和 QueryRow 在性能上几乎无差异——QueryRow 内部直接调用 Query，仅额外封装一层结果对象，其开销可忽略不计；选择应基于语义需求而非性能考量。
`query` 和 `queryrow` 在性能上几乎无差异——`queryrow` 内部直接调用 `query`，仅额外封装一层结果对象，其开销可忽略不计；选择应基于语义需求而非性能考量。
在 Go 的 database/sql 包中，Query 和 QueryRow 是两个最常用的查询方法，开发者常因“是否加 LIMIT 1”而纠结该选哪一个。简言之：二者性能几乎完全一致，差异不在执行效率，而在抽象语义与使用契约。
核心机制对比
Query(query, args...) 返回 *sql.Rows，适用于零行、单行或多行结果集。它会建立完整的游标（cursor），支持多次 rows.Next() 迭代，并要求显式调用 rows.Close()（或通过 defer 确保资源释放）。
QueryRow(query, args...) 返回 *sql.Row，是专为预期恰好一行（0 或 1 行）设计的便捷封装。其底层实现如下（简化示意）：
func (db *DB) QueryRow(query string, args ...interface{}) *Row {
rows, err := db.Query(query, args...) // ← 关键：内部直接调用 Query
if err != nil {
return &Row{err: err}
}
return &Row{rows: rows} // 封装后仅暴露 Scan 方法
}
可见，QueryRow 并未跳过网络传输、SQL 解析或数据库执行环节——它只是对 Query 结果做轻量级包装，并限制后续操作（如不支持 Next()，只提供 Scan()）。因此，即使 SQL 中已含 LIMIT 1，Query 本身也不会因此“变快”，而 QueryRow 也绝非“优化版”。
正确使用示例与注意事项
✅ 推荐场景：
- 用 QueryRow 获取单条记录（如 SELECT id, name FROM users WHERE id = ?）：
var name string err := db.QueryRow("SELECT name FROM users WHERE id = ?", 123).Scan(&name) if err == sql.ErrNoRows { // 处理未找到 } else if err != nil { // 处理其他错误 }
✅ 推荐场景：
-
用 Query 处理多行、流式读取或需自定义遍历逻辑的情况：
rows, err := db.Query("SELECT id, email FROM users WHERE active = ?", true) if err != nil { log.Fatal(err) } defer rows.Close() // 必须关闭！ for rows.Next() { var id int var email string if err := rows.Scan(&id, &email); err != nil { log.Fatal(err) } // 处理每行 } if err := rows.Err(); err != nil { log.Fatal(err) }
⚠️ 重要提醒：
- QueryRow 的 Scan() 方法自动关闭底层 Rows，无需手动管理；但若误用 QueryRow 执行本应返回多行的查询（如遗漏 WHERE 条件），将静默截断结果（仅取第一行），且无法感知被忽略的其余行——这属于逻辑错误，而非性能问题。
- Query 忘记 rows.Close() 会导致连接泄漏，长期运行可能耗尽连接池，这是比微秒级函数调用开销严重得多的问题。
总结
不必为性能在 Query 和 QueryRow 之间权衡：它们的数据库交互成本完全相同，差异仅在于 API 语义和资源管理契约。优先选择能准确表达业务意图的方法——用 QueryRow 声明“我只要一行”，用 Query 声明“我准备处理多行”。清晰的语义不仅提升代码可读性，更能规避隐式错误，这才是真正的工程效能优化。
