Query 和 QueryRow 在 database/sql 包中性能差异极小——QueryRow 内部实际调用 Query，仅额外封装一层结果；真正影响性能的是数据库往返、查询复杂度与数据量，而非方法选择。
`query` 和 `queryrow` 在 `database/sql` 包中性能差异极小——`queryrow` 内部实际调用 `query`，仅额外封装一层结果；真正影响性能的是数据库往返、查询复杂度与数据量，而非方法选择。
在 Go 的标准库 database/sql 中，Query 和 QueryRow 是两个高频使用的查询方法，常被开发者用于执行 SELECT 语句。尽管它们语义不同（前者用于多行结果，后者专为单行设计），但一个常见误区是认为添加 LIMIT 1 后改用 QueryRow 能显著提升性能。事实并非如此。
核心机制解析
QueryRow 并非独立实现的轻量级查询路径，而是对 Query 的语义封装。其源码逻辑清晰体现这一点（简化示意）：
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} // 封装为 Row，自动调用 Next() + Scan()
}可见，QueryRow 会完整执行一次 Query，获取 *Rows，再通过内部状态机确保仅读取首行并自动关闭结果集。因此，网络 I/O、SQL 解析、执行计划、磁盘/内存扫描等耗时环节完全一致——二者在数据库侧的开销 100% 相同。
如何正确选择？看语义，而非性能
| 场景 | 推荐方法 | 原因 |
|---|---|---|
| 确保且仅需 1 行结果（如 SELECT name FROM users WHERE id = ?） | QueryRow | 自动处理 Next() + Scan()，避免手动校验 rows.Next() 和 rows.Close()，代码更简洁安全 |
| 可能返回 0 行、1 行或多行（如分页、聚合统计） | Query | 提供对 Rows 的完整控制，支持迭代、批量 Scan、自定义错误处理 |
✅ 正确示例（单行查询）：
var name string
err := db.QueryRow("SELECT name FROM users WHERE id = $1", 123).Scan(&name)
if err == sql.ErrNoRows {
log.Println("user not found")
} else if err != nil {
log.Fatal(err)
}
// QueryRow 自动关闭 rows，无需 defer 或显式 Close❌ 错误优化（以为加 LIMIT 1 就该强制用 QueryRow）：
// ❌ 无性能收益，且语义失当：若业务上本应允许多行，却用 QueryRow 会静默截断
rows, _ := db.Query("SELECT * FROM logs WHERE level = $1 LIMIT 10", "ERROR")
// ✅ 此处必须用 Query —— 即使加了 LIMIT，目标仍是多行结果集注意事项与最佳实践
- 不要为“省一次函数调用”而切换方法：QueryRow 的额外函数调用开销在纳秒级，远低于任意一次数据库 round-trip（通常毫秒级）。
- 警惕隐式错误处理：QueryRow.Scan() 遇到 0 行时返回 sql.ErrNoRows，而 Query 需手动检查 rows.Next()；二者错误语义不同，需按业务逻辑选型。
- 资源安全优先：QueryRow 自动管理 Rows 生命周期，降低泄漏风险；Query 必须显式 defer rows.Close()，否则可能引发连接池耗尽。
- 性能瓶颈永远在数据库侧：优化方向应聚焦于索引、查询计划、连接池配置（SetMaxOpenConns）、批量操作等，而非 API 方法选择。
总之，Query 与 QueryRow 是同一查询引擎上的两扇门——门把手形状不同，但通向同一个房间。选择依据应是“你想取回多少数据”，而不是“哪扇门开关更快”。
