租户数据混存时必须显式校验tenant_id以避免查询越界，所有读写操作需强制携带tenant_id条件，Schema层用Mongoose钩子和JSON Schema校验，索引须以tenant_id为前导字段，分片键宜选hashed tenant_id以防数据倾斜。
租户数据混存时如何避免查询越界
多租户场景下最危险的不是性能差，而是 tenant_id 过滤漏写导致 A 租户看到 B 租户的数据。MongoDB 本身不提供行级租户隔离，全靠应用层兜底。
- 所有读写操作必须显式带上
tenant_id查询条件，不能依赖中间件自动注入（中间件可能绕过） - 在 Schema 层强制校验：用 Mongoose 的
pre('find')和pre('save')钩子检查tenant_id是否存在且非空 - 聚合管道中尤其容易漏——
$lookup后的子集合也得手动加tenant_id过滤，否则关联结果会跨租户 - 索引必须包含
tenant_id作为前导字段，比如{ tenant_id: 1, created_at: -1 }，否则即使写了过滤条件也走不了索引
集合按租户拆分是否真能提升性能
拆成 orders_tenant_123、orders_tenant_456 这类动态集合名，看似隔离彻底，实则带来新问题。
- 集合数量爆炸后，MongoDB 的 namespace 元数据开销明显上升，尤其在分片集群中，
config.collections文档会变大，影响路由元数据加载速度 - 无法使用跨集合聚合（
$lookup只支持同数据库内固定集合名），租户间统计类需求得退回到应用层合并 - 备份恢复复杂：mongodump 必须动态生成集合列表，脚本易出错；单个租户误删集合时，无法用
collMod恢复，只能从备份里捞 - 真正受益的场景只有两类：租户数据量级差异极大（比如一个租户占 90% 数据），或合规要求物理隔离（如 GDPR 强制磁盘级分离）
如何用单集合 + 复合索引平衡隔离与运维成本
绝大多数 SaaS 应用更适合单集合方案，关键在索引设计和查询约束。
- 集合命名保持业务语义，如
orders，不要带租户标识 - 每个文档必须有
tenant_id字段，类型统一用ObjectId或string（避免混用导致索引失效） - 创建唯一复合索引：
{ tenant_id: 1, external_id: 1 }，防止租户内重复订单号；再建高频查询索引，如{ tenant_id: 1, status: 1, updated_at: -1 } - 用 MongoDB 5.0+ 的
document validation规则强制tenant_id存在：{ $jsonSchema: { required: ["tenant_id"], properties: { tenant_id: { bsonType: "string" } } } }
分片键选 tenant_id 的实际效果
在分片集群中把 tenant_id 当分片键，听起来很自然，但要注意它和查询模式是否匹配。
- 如果大部分查询都带
tenant_id，且租户数据分布均匀，这是最优解——查询能路由到单个 shard，无跨分片压力 - 但如果存在“超级租户”（数据量超其他租户百倍），会导致 chunk 分裂不均，某些 shard 负载飙升，甚至触发
balancer长期无法收敛 - 更麻烦的是，一旦选了
tenant_id作分片键，就不能再用sh.splitAt()手动控制 chunk 边界，因为 MongoDB 要求分片键值必须单调递增或哈希稳定 - 替代方案：用
{ tenant_id: "hashed" }，牺牲部分范围查询能力，换得数据在 shards 间更均匀分布
tenant_id 写错一次，就可能泄露数据；索引少建一个字段，慢查询就会在凌晨三点把你叫醒。真正难的不是方案选择，而是让每个开发、每次提交、每条 SQL（哦不对，是 BSON 查询）都默认带上租户上下文。 
