Query 和 QueryRow 在 Go 的 database/sql 包中性能几乎无差别——QueryRow 内部直接调用 Query，仅额外封装一层轻量对象，数据库往返开销远超函数调用成本。
`query` 和 `queryrow` 在 go 的 `database/sql` 包中性能几乎无差别——`queryrow` 内部直接调用 `query`，仅额外封装一层轻量对象，数据库往返开销远超函数调用成本。
在 Go 应用开发中，常需从数据库获取单行结果（如用户登录验证、配置查询等），此时开发者常面临选择：使用 db.Query() 配合 rows.Next() + rows.Scan()，还是直接使用更语义明确的 db.QueryRow()？许多人误以为 QueryRow 因“专为单行设计”而更高效，甚至刻意添加 LIMIT 1 后仍坚持用 Query，实则并无必要。
事实上，QueryRow 并非独立实现，而是对 Query 的薄封装。其源码逻辑清晰可证（database/sql/sql.go）：
func (db *DB) QueryRow(query string, args ...interface{}) *Row {
rows, err := db.Query(query, args...)
if err != nil {
return &Row{err: err}
}
return &Row{rows: rows}
}
可见：
✅ QueryRow 必然触发一次完整的 Query 调用，产生完全相同的网络 I/O、连接复用、预处理（如启用）及驱动层开销；
✅ 额外成本仅为一次函数调用 + 一个 *Row 结构体分配（约几纳秒），在典型数据库 RTT（毫秒级）面前可忽略不计；
✅ 即使 SQL 中已含 LIMIT 1，Query 返回的 *Rows 仍需手动检查 Next() 并确保只读一行，而 QueryRow 通过 Scan() 自动隐式约束——这是语义与安全性的提升，而非性能优化。
因此，选型应基于使用场景而非性能：
- ✅ 优先用 QueryRow：预期严格返回 0 或 1 行（如 SELECT id, name FROM users WHERE email = ?），代码更简洁、错误处理更自然（Scan() 直接返回 sql.ErrNoRows）；
- ✅ 必须用 Query：需遍历多行、流式处理、或需访问 Columns() 元信息等高级能力；
- ⚠️ 注意：QueryRow 不校验实际返回行数是否 ≤1 —— 若 SQL 意外返回多行，Scan() 仅读取第一行，其余被静默丢弃（无警告）。务必确保业务逻辑与 SQL 语义一致（如主键/唯一索引查询）。
总结：二者性能无实质差异，QueryRow 是 Query 的语义增强版。与其纠结微秒级函数开销，不如聚焦于连接池配置、索引优化、批量操作等真正影响 QPS 的环节。写出清晰、健壮、符合直觉的代码，才是 Go 数据库编程的最佳实践。
