为何升序排序的复合索引搭配$lt查询速度极慢？

你的核心问题是复合索引的顺序完全搞错了，导致MongoDB无法利用索引同时完成过滤和排序，只能做低效的全量扫描后逐一校验条件。

为什么当前索引失效？ #

你建的索引是{status: -1, date: -1, counter: 1}，对应的查询逻辑是：status等值匹配 → date排序 → counter范围过滤。但MongoDB复合索引有个关键限制：当排序字段放在范围字段之前时，范围过滤无法利用索引，只能在排序后逐个校验文档是否符合条件。

在你的场景里，MongoDB会先通过索引取出所有status: "waiting"的文档并按date降序排列，但这些文档的counter值是无序的（因为counter在索引里跟在date之后，仅在相同date下有序）。这就意味着MongoDB必须遍历这些排序后的文档，逐一检查counter是否符合{$lt:3, $gte:0}的条件，直到攒够1500条符合要求的结果——这就是为什么会出现“扫描数十万文档才得到1500条结果”的情况。

正确的索引方案 #

调整索引顺序为：

{status: 1, counter: 1, date: -1}

这个索引的逻辑完全匹配你的查询需求：

1. 先通过status: "waiting"等值过滤，快速定位目标文档子集；
2. 再通过counter的范围条件{$lt:3, $gte:0}进一步缩小结果集，这一步直接利用索引过滤，无需扫描无关文档；
3. 最后索引中date: -1的排序规则，让符合条件的文档已经是按date降序排列的，MongoDB可以直接返回结果，不需要额外排序操作。

额外注意事项 #

• 检查字段名一致性：你给出的数据示例里时间字段是time，但查询排序用的是date，如果是笔误，必须修正字段名，否则索引完全无法匹配排序需求；
• 用db.collection.find(yourQuery).sort(yourSort).explain("executionStats")查看查询计划，确认executionStats.totalKeysExamined和executionStats.nReturned的数值接近，这才说明索引被高效利用。

是否需要更换查询方式？ #

不需要更换查询逻辑，只要调整索引顺序就能解决问题。如果业务上有特殊需求（比如必须优先获取最新date的文档，哪怕counter符合条件的数量极少），可以考虑先取最新的一批status: "waiting"文档，再在应用层过滤counter条件，但这种方式只适合小批量数据，远不如调整索引高效。

内容的提问来源于stack exchange，提问作者Drake Michiu