复合索引不能全字段生效是因为MongoDB按最左前缀原则匹配，查询必须从最左字段连续匹配，跳过中间字段或顺序/方向不一致时，右侧字段完全失效；范围条件后字段失去有序性，导致排序或过滤无法下推。
复合索引为什么不能全字段生效
MongoDB 复合索引不是“全有或全无”，而是按定义顺序逐层生效的。只要查询条件没从最左字段开始连续匹配，右侧字段就完全不参与索引查找——不是慢，是压根不用。
比如索引 {userId: 1, status: 1, createdAt: -1}：
-
{userId: "U123"}→ 用到userId前缀，OK -
{userId: "U123", status: "PENDING"}→ 用到前两个字段，OK -
{status: "PENDING"}→status不是最左，索引直接跳过，执行COLLSCAN -
{userId: "U123", createdAt: {"$gt": ISODate("2026-01-01")}}→ 跳过status，createdAt条件无法下推，只用上userId
范围字段位置不当导致后缀失效
范围查询（$gt、$in、$regex 等）一旦出现，它右边所有字段在索引中就失去排序和过滤能力。这不是 bug，是 B-tree 结构决定的：范围打断了后续字段的全局有序性。
典型错误索引：{service: 1, level: 1, timestamp: -1}，配合查询：.find({service: "api", level: {$in: ["error", "warn"]}}).sort({timestamp: -1})
-
service等值匹配成功 -
level是范围 →timestamp无法用于排序，MongoDB 必须 FETCH 全量匹配文档后再内存排序（SORT阶段） - explain 中会看到
"totalDocsExamined" > "totalKeysExamined"，就是这个信号
正确顺序应是 {service: 1, timestamp: -1, level: 1}：等值 → 排序 → 范围。
排序字段方向/顺序不匹配时索引“半残废”
即使所有字段都出现在查询里，只要 .sort() 的字段顺序或方向和索引不一致，排序就无法走索引。
- 索引
{a: 1, b: -1}可支持.sort({a: 1, b: -1})或.sort({a: -1, b: 1})（全反向） - 但
.sort({b: 1, a: 1})永远不命中该索引——B-tree 里数据是先按a再按b排的，反过来就是乱序 - explain 中若
executionStages.stage === "IXSCAN"但仍有"stage": "SORT"子节点，说明排序没被索引覆盖
低选择性字段前置让整个索引变重
把区分度低的字段（如 status 只有 3 个值）放在最左，相当于强制 MongoDB 先分 3 大桶，每桶再查——B+ 树深度没减少，IO 和内存反而更吃紧。
真实影响：
- 索引体积更大，缓存命中率下降
- 即使查询带
userId，也要先遍历所有status分支才能定位，nscannedKeys显著升高 - explain 中
"nReturned"远小于"nScannedObjects"，就是剪枝能力差的表现
真正关键的不是“字段要不要进索引”，而是“谁打头阵”。高选择性字段（如 userId、orderId）必须靠前，否则后面再精准也白搭。
