如何在MongoDB中设计支持多租户隔离查询的复合索引？-MongoDB-PHP中文网

复合索引必须以tenant_id为最左前导字段，否则无法高效过滤单租户数据，易导致全表扫描；正确顺序如{tenant_id:1,created_at:-1}，错误顺序如{created_at:-1,tenant_id:1}会使索引失效。

如何在mongodb中设计支持多租户隔离查询的复合索引？

复合索引必须包含租户ID字段

多租户场景下，tenant_id 是天然的查询过滤前缀。如果索引不以 tenant_id 开头，MongoDB 无法高效定位单租户数据，会导致全集合扫描（COLLSCAN）。即使后续字段选择性很高，缺失前置租户约束也会让索引失效。

常见错误是把业务主键（如 order_id）或时间字段（如 created_at）放在最左位，结果所有租户的数据混在一起排序，查询时仍需遍历大量无关记录。

✅ 正确顺序：{ tenant_id: 1, created_at: -1, status: 1 }
❌ 错误顺序：{ created_at: -1, tenant_id: 1, status: 1 }（tenant_id 不在最左，无法用于范围裁剪）
⚠️ 注意：即使应用层已确保每次查询都带 tenant_id，MongoDB 也不会“智能推导”其存在，索引结构必须显式体现

按高频查询模式补全字段顺序

租户ID之后的字段顺序，取决于实际 find() 或 aggregate() 中的 filter、sort 和 projection 组合。MongoDB 复合索引遵循“前缀匹配”原则——只有连续从左开始的字段能被用于过滤或排序。

例如，若常查 “某租户下指定状态的最新10条订单”，对应查询为：db.orders.find({ tenant_id: "t1", status: "paid" }).sort({ created_at: -1 }).limit(10)，则索引应为：{ tenant_id: 1, status: 1, created_at: -1 }。

状态字段 status 放在 created_at 前，才能支持 tenant_id + status 的等值过滤
created_at: -1 紧跟其后，使 sort() 直接复用索引顺序，避免内存排序（in-memory sort）
若还有分页需求（如 skip(100)），该索引仍有效；但深度分页性能会下降，需考虑游标方案

慎用稀疏索引或部分索引替代租户字段

有人试图用 sparse: true 或 partialFilterExpression 来“节省空间”，比如只对非空 tenant_id 建索引。这在多租户系统中极危险——一旦某文档 tenant_id 为 null 或缺失，它将完全不在索引中，导致查询遗漏或逻辑错误。

mongodb-query

用于调试和故障排查，查询MongoDB数据库。用户需要时可以： (1) 列出所有数据库； (2) 列出数据库中的集合； (3) 执行MongoDB查询或命令。

下载

租户隔离是强一致性要求，不能靠索引“选择性覆盖”。所有文档必须有明确、非空、不可变的 tenant_id，且索引必须无条件包含它。

❌ 避免：{ tenant_id: 1, ... }, { sparse: true }（tenant_id: null 文档不可见）
❌ 避免：{ partialFilterExpression: { tenant_id: { $exists: true } } }（同上，且可能掩盖数据质量问题）
✅ 强制写入校验：在应用层或数据库级（如 MongoDB 5.0+ 的 schema validation）确保 tenant_id 字段必填、类型为字符串、长度合规