Hyperf 不支持跨库 JOIN 查询，需用应用层关联、视图/物化表、消息队列缓存或最终一致性方案替代；多库事务无法原子提交，须避免跨库事务，改用 TCC 或本地消息表。
Hyperf 不支持跨库 JOIN 查询，这是由底层 PDO 和 MySQL 协议限制决定的，不是框架配置能绕过的。实际开发中必须换思路，不能强行写 JOIN db2.users ON orders.user_id = db2.users.id 这类语句。
用应用层关联替代 SQL 跨库 JOIN
把原本一次数据库 JOIN 拆成两次独立查询，在 PHP 层做数据拼接。适合主表数据量可控、关联字段有索引的场景。
- 先查主库订单：
Order::connection('orders_db')->where(...)->get() - 提取所有
user_id数组，去用户库批量查：User::connection('users_db')->whereIn('id', $userIds)->get()->keyBy('id') - 循环订单集合，用
$users[$order->user_id] ?? null补充用户信息
通过视图或物化表统一数据出口
如果跨库关联是高频且稳定的业务需求，建议在 MySQL 层解决，而不是让 PHP 承担关联逻辑。
- 在其中一个库（如主库）创建视图，用
FEDERATED引擎或MySQL Router + DNS 别名映射远端表（需 DBA 配合） - 更稳妥的做法是定时同步关键字段到本地库，例如每天凌晨将
users的id, name, email同步到orders_db.user_summary表 - Hyperf 模型直接查本地表，
Order::with('userSummary')→get()，完全规避跨库问题
用消息队列或缓存做最终一致性关联
适用于对实时性要求不高、但数据量大、读多写少的报表类场景。
- 用户信息变更时，发消息到 RocketMQ/Kafka，消费端更新 Redis 中的
user:{id}JSON 缓存 - 查订单时，用
Redis::mGet(['user:1001', 'user:1002', ...])批量取用户快照 - 不强依赖数据库一致性，降低主库压力，也避免跨库事务和锁竞争
注意连接切换与事务隔离的边界
即使不用 JOIN，多库操作仍存在隐含风险：
-
Db::connection('db1')->transaction()只对当前连接生效，无法跨库原子提交 - 若需“订单写入 + 用户积分扣减”这类跨库操作，必须用最终一致性方案，比如 TCC 或本地消息表
- Eloquent 模型的
$connection属性只影响该模型的默认连接，with()关联加载仍走本模型连接，不会自动切到被关联模型的连接
