通配符索引不支持复合排序，因其将嵌套字段扁平化为独立索引条目，不保留路径层级关系与字段间相对顺序，无法提供跨子字段的联合排序语义。
通配符索引不支持复合排序的底层原因
当你对嵌套字段执行类似 db.collection.find({"customFields.addr": "Beijing"}).sort({"customFields.blockId": 1}) 的查询时，即使已建复合通配符索引 {"tenantId": 1, "customFields.$**": 1}，MongoDB 仍会触发内存排序而非利用索引物理顺序返回结果。
这是因为通配符索引在构建时将所有匹配子字段的值扁平化为独立键值对并分别索引，【不保留子字段之间的原始路径层级关系或相对顺序】。例如 customFields.addr 和 customFields.blockId 在索引中是两条完全分离的索引条目，彼此无序关联。
而排序操作要求字段间存在确定的联合排序语义——即“先按 addr 升序，addr 相同时再按 blockId 升序”。通配符索引无法提供这种跨子字段的联合排序能力，它只保证单个子字段内部的有序性。
验证是否真的走了索引排序
运行以下命令查看执行计划：
db.collection.explain("executionStats").find({"customFields.addr": "Beijing"}).sort({"customFields.blockId": 1})
如果输出中出现 "stage": "SORT" 且 "nReturned" 远小于 "totalDocsExamined"，说明排序未下推；若看到 "stage": "IXSCAN" 后紧跟 "stage": "SORT"，则证实索引仅用于过滤，排序仍在内存中完成。
真正有效的索引排序表现是：整个执行链中没有 SORT 阶段，或 sortStage 的 "works" 字段为 0。
替代方案：用明确路径索引代替通配符
方法一：为高频排序组合创建显式复合索引
例如针对 customFields.addr 过滤 + customFields.blockId 排序场景，直接建：
db.collection.createIndex({"customFields.addr": 1, "customFields.blockId": 1})
该索引满足前缀匹配（等值查询 addr）、字段顺序与使用顺序一致、且支持范围排序，能完整跳过内存排序阶段。
方法二：若需兼顾多个子字段组合，优先建 2～3 个高选择性显式复合索引，而非依赖一个通配符索引覆盖全部。MongoDB 每集合最多 64 个索引，但实际业务中 5～8 个精心设计的复合索引通常比 1 个通配符索引更高效、更可控。
【通配符索引不能与显式字段索引共存于同一查询的排序路径中——优化器不会混合使用它们来构造排序顺序】。一旦查询涉及排序，就必须有对应字段的非通配符复合索引支撑。
