在 Go 中初始化多个数据库连接实例需为每个数据源单独调用 sql.Open 创建独立 *sql.DB 实例，命名明确（如 userDB、orderDB），分别配置连接池参数，避免共享或动态切换数据库。
如何在 Go 中初始化多个数据库连接实例
Go 本身不提供“多数据源”抽象层，所谓多数据源，本质是手动维护多个独立的 *sql.DB 实例，每个对应不同 DSN。关键不是“配置”，而是避免全局单例污染和连接复用冲突。
常见错误是把所有 DSN 塞进一个 database/sql.Open 调用，或试图用同一个 *sql.DB 切换数据库（MySQL 支持 USE db_name，但事务、连接池、超时等行为不可控，不推荐）。
- 为每个数据源单独调用
sql.Open，传入各自 DSN - 给每个实例起明确变量名，例如
userDB、orderDB，而非db1、db2 - 务必调用
SetMaxOpenConns、SetMaxIdleConns等参数——不同业务库负载差异大，共用默认值易导致连接耗尽或空闲堆积 - 初始化失败时立即返回错误，不要静默 fallback 或重试（配置错误应暴露，而非掩盖）
YAML 配置文件里怎么组织多个数据源字段
结构要扁平可扩展，避免嵌套过深。用一级 key 区分数据源名称，每个 value 是完整连接配置，而不是把 host/user/password 拆成顶层字段。
示例 config.yaml：
立即学习“go语言免费学习笔记（深入）”；
mysql:
user_db:
dsn: "user:pass@tcp(10.0.1.10:3306)/user_center?charset=utf8mb4&parseTime=True"
max_open_conns: 20
max_idle_conns: 10
order_db:
dsn: "order:pass@tcp(10.0.1.11:3306)/order_service?charset=utf8mb4&parseTime=True"
max_open_conns: 50
max_idle_conns: 20
注意：dsn 中的 & 是 YAML 字符串里的字面量，不是 HTML 实体；解析时直接传给 sql.Open 即可，无需额外 decode。
- 不要把密码硬编码在 YAML 里，生产环境应通过环境变量注入，如
dsn: "${ORDER_DB_USER}:${ORDER_DB_PASS}@tcp(...)" - 不同数据源的
max_open_conns必须差异化设置——报表库读多写少，可设高些；支付库要求强一致性，连接数宜保守 - 避免使用
default作为数据源名，容易和配置工具的默认逻辑冲突
如何防止事务跨数据源误用
Go 的 sql.Tx 绑定到单一 *sql.DB 实例，天然不支持跨库事务。但开发者常误以为“开了事务就能保证多库一致”，结果只在部分库生效，还自以为成功。
最稳妥的做法是：显式禁止跨源操作。
- 把每个
*sql.DB封装进独立 service struct，例如UserRepo{db *sql.DB}和OrderRepo{db *sql.DB}，方法签名不暴露*sql.DB - 事务逻辑限定在单个 repo 内部，跨库协调交给上层应用层（如 Saga 模式），而非尝试用
tx.Commit()覆盖多个 DB - 单元测试里故意在同一个
sql.Tx上执行两条不同 DB 的Query，会直接 panic：“sql: transaction has already been committed or rolled back”，这是好事——早点暴露误用
为什么不能用 sql.Open("mysql", dsn) 之后再改 database 名
MySQL 协议层面，database/sql 在 sql.Open 时解析 DSN 中的数据库名，用于初始化连接上下文。后续执行 USE other_db 只影响当前连接的默认库，但：
- 连接池中的其他连接仍指向原库，下次复用时行为不可预测
-
sql.Tx创建时继承的是连接初始库，不是USE后的库 - 很多 ORM（如 GORM）会在建表、迁移时依赖 DSN 中的库名，动态切换会导致 schema 错乱
- PostgreSQL 完全不支持运行时切换 database，DSN 中的
dbname=xxx是强制且不可覆盖的
真正需要灵活切换的场景（比如租户隔离），应该用连接池分组或数据库名拼接（如 SELECT * FROM tenant_001.users），而不是靠 USE。
