在go中，`database/sql.db` 是线程安全的连接池抽象，应全局初始化一次并复用；频繁调用`sql.open`不建立实际连接，也不提升并发能力，反而增加资源开销和配置管理复杂度。
Go 的 database/sql 包设计核心之一就是连接池化与长期复用。sql.Open 函数本身并不立即建立数据库连接，它仅负责解析数据源名称（DSN）并返回一个 *sql.DB 实例——该实例内部维护了一个可自动伸缩、并发安全的空闲连接池（idle connection pool）。真正的连接建立发生在首次执行查询（如 db.Query, db.Exec）或显式调用 db.Ping() 时。
因此，针对问题中“100个函数需访问同一数据库”的场景：
✅ *推荐做法（唯一正确方式）：全局单例初始化 `sql.DB** 在应用启动时（如main()或init()中）调用一次sql.Open，随后将该*sql.DB` 实例以依赖注入或全局变量方式传递/共享给所有业务函数。例如：
var db *sql.DB
func initDB() error {
var err error
db, err = sql.Open("mysql", "user:pass@tcp(127.0.0.1:3306)/mydb")
if err != nil {
return fmt.Errorf("failed to open db: %w", err)
}
// 关键：验证连接有效性，并触发真实连接建立
if err = db.Ping(); err != nil {
return fmt.Errorf("failed to ping db: %w", err)
}
// （可选）配置连接池行为，提升稳定性与性能
db.SetMaxOpenConns(25) // 最大打开连接数
db.SetMaxIdleConns(25) // 最大空闲连接数
db.SetConnMaxLifetime(5 * time.Minute) // 连接最大存活时间
return nil
}❌ 错误做法辨析
选项①（每个函数内 sql.Open）：
每次调用都创建新 *sql.DB 实例，导致多个独立连接池、重复解析 DSN、内存泄漏风险（若忘记 Close()），且无法复用底层 TCP 连接，严重浪费资源。更严重的是，它违背了 database/sql 的设计契约——DB 实例本就为高并发、长生命周期而生。选项②（“共用同一个连接”）表述不准确：
*sql.DB 本身不是“单个连接”，而是连接池管理者。100 个函数并发调用 db.Query(...) 时，底层会自动从池中获取、复用或新建连接，无需也不应手动控制“哪个函数用哪条连接”。所谓“共享 DB”即共享这个智能池，而非共享单条 socket 连接。
? 关键注意事项
- db.Close() 通常无需主动调用，除非程序即将退出且需优雅释放资源（如 CLI 工具、测试用例结束）；Web 服务等长运行进程应让 DB 实例常驻。
- 必须调用 db.Ping() 验证初始化成功——否则 sql.Open 的错误可能被静默忽略，直到首次查询才暴露，导致故障延迟发现。
- 合理配置 SetMaxOpenConns / SetMaxIdleConns 可避免连接耗尽或空闲连接堆积，尤其在高并发或短连接场景下至关重要。
总结：Go 数据库操作的黄金法则是——一次 Open，全程复用，按需 Ping，合理调优池参数。这既是性能最优解，也是官方文档明确倡导的最佳实践。
