mongodb事务不提供多租户隔离，租户隔离必须由应用层显式控制；漏写tenant_id会导致跨租户数据污染，聚合管道$lookup需手动补tenant_id过滤，跨库事务不支持，索引须以tenant_id为前导字段，备份恢复无法按租户粒度进行。
MongoDB 事务本身不提供多租户隔离能力，它只保证跨文档操作的原子性；租户隔离必须由应用层显式控制，否则事务反而会放大越界风险。
事务内漏写 tenant_id 条件会导致跨租户数据污染
在单集合逻辑隔离（discriminator field）模式下，如果事务中某个 updateOne 或 deleteMany 操作没带 tenant_id 查询条件，事务提交后，A 租户的数据可能被 B 租户的事务误删或覆盖——而 MongoDB 不会报错，因为语法完全合法。
- 聚合管道中的
$lookup无法动态指定目标集合名，若硬编码为"orders"，所有租户都会查同一张表，tenant_id过滤必须在后续$match阶段补上，且不能漏 - 使用
session.startTransaction()后，所有操作共享同一上下文，但不会自动注入租户上下文，tenant_id必须从请求头、JWT 或线程局部变量中手动提取并拼入每个查询条件 - Spring Data MongoDB 的
@Transactional注解默认不感知租户，需配合ThreadLocal+ 自定义ReactiveMongoTemplate才能拦截并重写查询条件
跨集合事务在多租户中基本不可用
如果你采用“每个租户一个数据库”的物理隔离方案，session.startTransaction() 无法跨数据库执行——MongoDB 明确限制事务只能作用于单个数据库内的集合。这意味着你不能在一个事务里同时操作 tenant_a.users 和 tenant_b.orders。
- 即便所有租户共用一个数据库但分库命名（如
tenant_123_users,tenant_123_orders），事务也无法覆盖这些动态命名的集合，因为事务启动前就必须声明参与集合列表 - 试图用
db.getSiblingDB("tenant_123").collection.find()在事务中调用，会直接抛出IllegalOperation: Cannot use db.getSiblingDB in a transaction - 真正可行的跨租户一致性保障，只能退回到应用层补偿：例如先写主租户数据，再发消息触发其他租户侧异步更新，靠幂等+重试兜底
索引设计不当会让 tenant_id 过滤失效
即使每次查询都写了 { tenant_id: "abc" }，如果集合上没有以 tenant_id 为前导字段的复合索引，MongoDB 可能全表扫描，不仅慢，还可能因内存不足触发 QueryExceededMemoryLimitNoDiskUseAllowed 错误，导致事务长时间挂起甚至超时回滚。
- 必须创建形如
db.orders.createIndex({ tenant_id: 1, created_at: -1 })的索引，而非{ created_at: -1, tenant_id: 1 }—— 后者无法支撑tenant_id精确匹配 - 分片集群下，若用
hashed tenant_id当分片键，务必确认所有事务操作都落在同一分片上；否则事务会失败并报TransactionNotSupportedOnShardedCluster - 使用
explain("executionStats")检查查询是否命中索引，重点关注executionStages.nReturned是否等于预期文档数，而非只看totalDocsExamined
备份与恢复时事务日志不保租户边界
mongodump 默认不区分租户，一次 dump 就是整个数据库快照。如果你靠单集合 + tenant_id 隔离，却用 mongorestore --drop 全量恢复，所有租户数据一起回来——但某个租户误删数据后，你没法只还原他那一部分。
- 按租户粒度备份需脚本动态生成集合白名单，例如
mongo --eval "db.getCollectionNames().filter(n => n.startsWith('tenant_'))"，再逐个 dump - WiredTiger 引擎的 oplog 是全局的，事务提交记录也混在其中，
mongorestore --oplogReplay会重放全部租户操作，无法按tenant_id过滤 - 真正安全的租户级恢复，依赖应用层逻辑：比如关键操作前先写一条带
tenant_id标记的审计日志到独立集合，出问题时靠它定位时间点和影响范围
最易被忽略的一点：事务的 readConcern: "snapshot" 和 writeConcern: { w: "majority" } 设置，在多租户高并发场景下会显著拖慢响应——不是功能问题，而是性能瓶颈常被误判为隔离失效。别急着加锁，先看是不是索引缺失或事务体过大。
