不支持。MongoDB事务明确禁止跨数据库操作，无论复制集或分片集群，事务仅限单数据库内集合；因oplog按库组织，跨库会破坏原子性与持久性，必须通过收拢数据、引用或最终一致性替代。
不支持。MongoDB 事务明确禁止跨数据库操作，无论你用的是复制集还是分片集群，session.startTransaction() 启动的事务只能作用于单个数据库内的集合。
为什么 MongoDB 禁止跨数据库事务
MongoDB 的事务实现依赖于底层存储引擎（WiredTiger）的 snapshot 隔离机制和 oplog 写入顺序，而 oplog 是按数据库粒度组织的。跨库操作会破坏事务日志的一致性边界，导致无法原子地回滚或恢复——这直接违反 ACID 中的原子性和持久性要求。
常见错误现象包括：
- 执行
db.getSiblingDB("other_db").collection.insertOne(...)时抛出InvalidNamespace或TransactionNotActive - 在事务中调用
session.getDatabase("other_db")后操作失败，且错误信息不直观，容易误判为权限或连接问题
替代方案：如何绕过跨库限制
实际业务中遇到“看似需要跨库”的场景，绝大多数可通过模型重构解决：
- 把逻辑上强关联的数据（如订单 + 用户积分）统一收拢到同一个数据库下，用命名空间区分（例如
orders和users.points集合） - 用引用代替跨库关系：在主库文档中存
points_ref: { db: "account_db", collection: "balances", id: ObjectId(...) }，后续通过应用层双写+幂等校验兜底 - 若必须物理隔离（如多租户），改用最终一致性模式：先提交主库事务，再发消息触发异步更新其他库，配合本地消息表或事务性发件箱（outbox pattern）
分片集群下尤其要注意的坑
即使你在同一数据库内操作多个集合，如果这些集合的分片键设计不合理，事务仍可能因涉及多个分片而失败（4.2+ 支持跨分片事务，但性能损耗大、超时风险高）：
- 确保所有参与事务的集合使用相同分片键，并且关键字段（如
user_id）值一致，让路由能定位到同一分片 - 避免在事务中查询未分片的集合（如
config.system.sessions），这类操作会直接报错 -
readConcern: "snapshot"是跨分片事务的强制要求，漏设会导致SnapshotUnavailable
真正棘手的不是语法能不能写，而是事务边界一旦画错，问题会藏在并发高峰时才暴露——比如两个事务同时修改不同库的关联数据，表面正常，实则留下数据漂移隐患。
