Beego原生ORM不支持自动读写分离，必须手动注册多个数据库别名并显式调用Using()指定库；事务内所有操作绑定初始库，不可跨库，且关联查询不继承Using，需分别指定或改用Raw()。
Beego 支持多数据库连接，但原生 ORM 不提供自动读写分离路由能力；必须手动注册多个数据库别名，并在代码中显式指定读库或写库。
如何注册多个 MySQL 数据库实例
Beego 的 orm.RegisterDataBase 允许你注册任意数量的数据库别名，只要别名不重复。默认的 "default" 仅是约定，不是强制——你可以完全不用它，改用 "master" 和 "slave" 等语义化名称。
常见错误是只注册一个库却试图“自动切读库”，结果所有查询仍走同一连接池。
- 必须为每个物理数据库单独调用
orm.RegisterDataBase，例如：
orm.RegisterDataBase("master", "mysql", "root:pass@tcp(127.0.0.1:3306)/myapp?charset=utf8mb4")
orm.RegisterDataBase("slave", "mysql", "readonly:pass@tcp(127.0.0.1:3307)/myapp?charset=utf8mb4")
- 连接字符串中的用户名、端口、参数（如
readTimeout）需按实际环境调整；slave库建议使用只读账号，避免误写 - 若用 MySQL 8+，注意驱动默认启用
parseTime=true，时间字段解析才可靠；可在 DSN 后追加&parseTime=true
为什么 QueryTable().Using() 是读写分离的关键入口
Beego ORM 没有内置基于 SQL 类型（SELECT/INSERT）的自动分发逻辑。所有读写分离动作都依赖你在执行查询前显式调用 .Using("slave") 或 .Using("master")。
容易踩的坑：在事务中混用 Using —— Beego 不支持跨库事务，Begin() 只作用于当前 Ormer 实例绑定的数据库。
- 读操作示例（强制走从库）：
o := orm.NewOrm().Using("slave")
var users []User
o.QueryTable("user").Filter("status", "active").All(&users)
- 写操作必须明确指向主库：
o := orm.NewOrm().Using("master")
_, err := o.Insert(&user)
- 关联查询（如
RelatedSel）不会继承Using，需对主表和关联表分别指定库，或改用原生 SQL +Raw()控制
事务与读写分离冲突时的实际处理方式
一旦调用 o.Begin()，后续所有操作（包括 Read、Update、LoadRelated）都绑定到该 Ormer 实例初始的数据库连接，.Using() 不再生效。
这意味着：你无法在一个事务里先查从库、再写主库——这本身也违背 ACID 原则。真实场景中，事务内所有操作必须落在同一物理库上。
- 正确做法：事务一律走
"master"，且不在事务中调用.Using("slave") - 若需“先读再判再写”，应拆成两步：先用
slave查询，再用master开启新事务执行写入 - 注意
Raw()查询不受Using()影响，除非你传入的是已绑定库的Ormer实例
连接池参数对读写分离效果的影响
不同数据库别名可配置独立的连接池大小，这对读写分离的负载均衡很关键。比如写库压力小但要求强一致性，可设较小 maxIdle；读库并发高，需调大 maxConn。
忽略这点会导致：从库连接池打满后请求排队，反而比单库更慢。
- 注册时传入连接池参数（Go 1.2+）：
orm.RegisterDataBase("slave", "mysql", dsn, 50, 200) // maxIdle=50, maxConn=200
- 生产环境建议：主库
maxConn设为 50~100，从库根据读 QPS 设为 150~300 - Beego 不暴露底层
*sql.DB的SetConnMaxLifetime，如有连接老化问题，需升级驱动或改用自定义 DB 实例注入
真正麻烦的从来不是配两个数据库，而是让每个业务函数清楚自己该读哪个库、是否在事务里、关联数据要不要预加载——这些决策没法靠框架自动完成，得靠代码注释和团队规范兜底。
