Partial Indexes 是解决多租户索引膨胀最直接有效的方法，通过为每个活跃租户单独创建 partialFilterExpression 匹配其 tenantId 的索引，使索引体积减少 60%–95%，写入延迟下降，热数据更易驻留内存。
多租户场景下，索引膨胀是隐蔽但致命的性能瓶颈——同一张集合里混存多个租户数据，却为所有租户共用一套索引，导致 keysExamined 远大于 nreturned（比如慢日志中扫描 1498 条索引只返回 3 条文档），索引体积和写入开销双双失控。Partial Indexes 是最直接有效的解法。
为什么普通索引在多租户下会失效
租户数据通常通过字段如 tenantId、orgId 或 workspaceId 标识。若只建 { tenantId: 1, createdAt: -1 } 这类复合索引，MongoDB 仍需为每个插入的文档（无论属于哪个租户）都写入索引条目。当租户数达数百、单租户日增万级文档时，索引文件迅速膨胀，内存无法全量缓存，磁盘随机读加剧，CPU 和 IO 压力同步飙升。
更关键的是：查询时即使带上 tenantId，只要索引本身没做裁剪，MongoDB 仍要遍历整个索引树中该 tenantId 对应的所有键，而这些键可能散落在不同页、跨多个磁盘块。
- 常见错误现象：监控显示
keysExamined ≈ docsExamined ≫ nreturned，且planSummary显示IXSCAN但效率极低 - 使用场景：SaaS 应用、ISV 平台、共享数据库实例中的租户隔离
- 性能影响：索引体积可减少 60%–95%，写入延迟下降明显，热数据更易驻留内存
Partial Indexes 的正确写法与限制
Partial Index 不是“按租户动态建索引”，而是定义一个布尔表达式，让 MongoDB 只为满足条件的文档建立索引条目。对多租户来说，核心就是把 tenantId 的具体值固化进索引定义中——但注意，不能写成 { tenantId: "abc123" }，那会变成固定值索引，毫无通用性。
真正可行的方式是：为每个活跃租户单独创建一个 partial index，表达式严格匹配其 tenantId 值：
db.orders.createIndex(
{ status: 1, createdAt: -1 },
{ partialFilterExpression: { tenantId: "t-789" } }
)
这个索引只包含 tenantId === "t-789" 的文档，其他租户数据完全不进入该索引结构。
- 必须用
partialFilterExpression，不能用query或其它字段；表达式只支持等值、$in、$exists、$lt/$gt等简单操作符，不支持$or、$regex - 查询时必须显式带上
tenantId: "t-789"，否则 MongoDB 不会考虑该 partial index（即使其他条件完全匹配） - 不能对同一个字段组合重复建多个 partial index（例如同时建
{tenantId:"a"}和{tenantId:"b"}），MongoDB 允许，但管理成本陡增；建议配合自动化脚本按租户生命周期创建/删除
如何避免踩坑：覆盖查询 + 查询路由
Partial Index 本身不解决“查哪个索引”的问题。应用层必须确保：查询条件中 tenantId 的值，与所用 partial index 的 partialFilterExpression 完全一致，且该索引已存在。否则会 fallback 到全表扫描或低效索引。
- 强制投影：在查询中明确指定所需字段，尽量让查询能被索引覆盖。例如建了
{ status: 1, createdAt: -1 }partial index，就只查{ status: 1, createdAt: 1, _id: 0 }，避免回表 - 路由控制：在 DAO 层或 API 网关做租户识别，解析请求中的
tenantId，再决定调用哪个索引路径；不要依赖 MongoDB 自动选择 - 监控验证：用
explain("executionStats")检查indexName是否命中预期的 partial index，并确认keysExamined接近nreturned - 清理机制：租户停用后，及时执行
db.collection.dropIndex({ status: 1, createdAt: -1 }, { partialFilterExpression: { tenantId: "t-789" } })，否则残留索引持续占用空间
Partial Indexes 不是银弹——它把索引管理从“静态统一”推向“动态分治”，代价是运维复杂度上升。最容易被忽略的一点：你得有可靠的租户元数据服务，能实时知道哪些租户活跃、哪些该归档，否则索引创建和清理就会脱节，反而引发更难排查的查询抖动。
