MongoDB 5.0 不支持动态索引过滤，partialFilterExpression 在索引创建时静态定义，仅在插入/更新时生效，查询时不会根据 $or、$in 或变量值动态启用索引，必须预先创建语义明确的 partial index 并严格匹配其过滤条件。
MongoDB 5.0 不支持“动态索引过滤”这个概念——它没有内置的、运行时可变条件的索引过滤机制（比如 PostgreSQL 的 partial index WHERE 条件那样按查询上下文自动启用/禁用索引）。所谓“动态索引过滤”，通常是开发者对 partialIndexFilter 或复合索引字段选择的误称，或混淆了查询谓词与索引扫描行为。
为什么不能在查询时“动态切换”索引过滤条件
MongoDB 的索引一旦创建，其结构（包括 partialFilterExpression）就是静态的，由 createIndex 命令一次性定义。查询执行器不会根据 $or、$in 或变量值去临时重写索引逻辑。
- 索引是否被选中，取决于查询谓词能否**覆盖**（cover）索引的键模式 + 过滤表达式，而不是“运行时判断要不要过滤”
-
partialFilterExpression只在索引构建和文档插入/更新时起作用：不满足该表达式的文档根本不会进入该索引 - 即使你写
{ status: { $in: ["paid", "refunded"] } }，MongoDB 也不会基于这个$in动态启用某个 partial index；它只看当前查询是否匹配索引定义里的partialFilterExpression
真正可行的替代方案：partialIndexFilter + 合理的查询设计
如果你的目标是“让高频子集查询走轻量索引”，正确做法是预先定义好语义明确的 partial index，并确保查询严格匹配其过滤条件。
- 必须用
createIndex显式声明，例如：db.orders.createIndex( { userId: 1, createdAt: -1 }, { partialFilterExpression: { status: "paid" }, name: "idx_paid_user_time" } ) - 只有当查询同时满足：
- 包含
status: "paid"（精确等值，不能是{ status: { $ne: "draft" } }） - 且查询字段前缀能命中索引键（如
{ status: "paid", userId: ObjectId("...") }）
- 包含
- 注意：partial index 无法配合
$or使用——如果查询是{ $or: [{ status: "paid" }, { status: "refunded" }] }，则必须建两个 separate partial index 并依赖查询优化器择一使用，或改用全覆盖索引
容易踩的坑：误以为 hashed 分片键能“动态路由”索引
有些团队试图用 { _id: "hashed" } 作为分片键，再配合 partial index 实现“按需过滤”。这是无效组合：
- 分片键决定数据物理分布，和索引是否生效无关
- partial index 仍受查询谓词限制；哪怕数据均匀打散，若查询没带
partialFilterExpression中的字段，索引照样不参与计划 - 更危险的是：对 hashed 字段做范围查询（如
{ _id: { $gt: ... } }）会退化为广播查询，彻底抵消分片价值
最常被忽略的一点：partial index 的 partialFilterExpression 必须是确定性布尔表达式，不能含变量、聚合变量（如 $$NOW）、或依赖 session 状态。它在索引元数据里固化，重启 mongod 也不变——所谓“动态”，只能靠应用层多建几个语义清晰的 partial index，然后由查询精准命中其中一个。
