不能直接用sql.open每次新建连接，因为会导致连接池失控、资源泄漏且无法复用连接；应预先创建并统一管理多个*sql.db实例，按需路由而非切换。
为什么不能直接用 sql.Open 每次新建连接？
直接在业务逻辑里反复调用 sql.Open 创建新连接，会导致连接池失控、资源泄漏，且无法复用已建立的连接池。Go 的 database/sql 包本身不支持运行时切换底层 *sql.DB 实例——它是个“连接池句柄”，不是轻量级代理。
真正要做的，是把不同数据库的 *sql.DB 实例预先建好、统一管理，并按需路由到对应实例。核心不是“切换 DB”，而是“按上下文选 DB”。
- 每个
*sql.DB必须独立调用sql.Open+db.Ping初始化，不能共享 driver 或 conn string - 连接池参数（如
SetMaxOpenConns）需按库单独配置，尤其混合 MySQL/PostgreSQL 时，行为差异大 - 别把
*sql.DB存在全局变量里裸奔——要用结构体封装 + sync.Map 或读写锁保护
如何设计可扩展的数据库注册与获取机制？
用一个中心化 registry 管理所有已注册的 *sql.DB，键名建议用业务语义而非技术名（比如 "user_primary" 而非 "mysql_192.168.1.10"），方便后续横向扩展分库或读写分离。
推荐用结构体封装 registry，避免依赖全局状态：
type DBRegistry struct {
mu sync.RWMutex
dbs map[string]*sql.DB
}
func (r *DBRegistry) Register(name string, db *sql.DB) {
r.mu.Lock()
defer r.mu.Unlock()
r.dbs[name] = db
}
func (r *DBRegistry) Get(name string) (*sql.DB, bool) {
r.mu.RLock()
defer r.mu.RUnlock()
db, ok := r.dbs[name]
return db, ok
}
- 注册前务必调用
db.Ping()验证连通性，否则首次查询才报错，排查成本高 - 不要在
Get里做 lazy init —— 动态加载新库会破坏事务一致性，且并发下易重复初始化 - 如果涉及租户隔离，
name可拼接租户 ID（如"tenant_abc_user"），但注意长度和字符限制
怎样让业务代码无感使用多 DB？
最实用的方式是把 DB 选择逻辑下沉到 DAO 层入口，而不是让 handler 或 service 层硬编码 registry.Get("xxx")。常见做法是通过 context 传递目标 DB 名，DAO 方法内部解析并获取对应 *sql.DB：
func (u *UserDAO) GetByID(ctx context.Context, id int64) (*User, error) {
dbName := ctx.Value("db_name").(string)
db, ok := registry.Get(dbName)
if !ok {
return nil, fmt.Errorf("db not registered: %s", dbName)
}
// 后续用 db.QueryRow(...) 即可
}
- 避免用字符串常量传
db_name，定义为 const（如const DBUserPrimary = "user_primary"）提升可维护性 - 如果 DAO 方法需跨库 join（比如查用户+订单），必须由上层显式拆成多个查询——SQL 层面无法跨库 join，强行封装只会掩盖问题
- 事务只能绑定单个
*sql.DB，跨库操作天然不支持 ACID，得靠最终一致性或 Saga 模式补位
哪些地方最容易踩坑？
动态切换的本质是“多实例 + 运行时路由”，不是语法糖。最容易出问题的地方往往不在主流程，而在边界和清理环节：
- 忘记关闭不再使用的
*sql.DB—— 调用db.Close()后，该实例不能再被Get返回，registry 应同步移除键值 - 用
context.WithValue传 DB 名时，没做类型断言防护，panic 直接崩服务 - 测试时只 mock 一个 DB，但线上因配置缺失导致
Get返回 false，业务逻辑未处理 fallback 路径 - MySQL 和 PostgreSQL 的 placeholder 不同（
?vs$1），混用驱动时 SQL 字符串不能通用，DAO 层要按 DB 类型分支处理
真正麻烦的从来不是“怎么切”，而是“切完之后，连接生命周期、事务边界、错误归因、监控指标”怎么对齐。这些细节不提前想清楚，上线后查问题比写代码还累。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
