DocumentDB聚合查询未使用_id索引的原因及优化建议咨询

1. 为何查询未使用_id索引？ #

你的查询中对_id使用了$regex匹配，但非前缀匹配的正则无法利用单键索引（如果你的正则不是以^开头的前缀匹配）。MongoDB/DocumentDB的索引是有序结构，只有前缀匹配的正则能通过索引快速定位文档范围，非前缀正则只能遍历全表（COLLSCAN）来匹配符合条件的文档。

另外，你拆分了多个$match阶段，虽然数据库会尝试合并，但如果早期的过滤条件无法有效缩小数据集，查询优化器也可能放弃使用索引，选择全表扫描。

2. 创建colId字段的索引是否会有帮助？ #

如果colId:"DATA"这个条件能过滤掉大部分文档，创建{colId: 1}的单键索引会有明显帮助——它能让查询先快速筛选出colId为DATA的文档，再处理_id的正则匹配，大幅减少后续阶段需要处理的数据量。

如果你的_id正则是前缀匹配（比如^DATA_），还可以创建复合索引{colId: 1, _id: 1}，进一步提升过滤效率，查询优化器可以同时利用两个条件快速定位目标文档。

额外优化建议 #

• 合并多个$match阶段：将所有前置过滤条件合并到一个$match中，让查询优化器更好地评估索引使用策略，示例：

  {$match: {
    _id: { $regex: '你的前缀正则'},
    colId: "DATA"
  }}
  

• 使用前缀正则：将_id的正则改为前缀匹配（如^xxx），这样可以直接利用_id的默认索引，避免全表扫描。
• 尽早过滤数据：所有$match都放在聚合管道最前面，尽可能早地减少后续$unwind、$group等阶段需要处理的文档数量——$unwind会将数组展开为多个文档，数据量可能翻倍，前置过滤的收益非常大。
• 评估数组字段索引：如果data.time和data.col的过滤是核心条件，可以考虑创建索引{colId:1, data.time:1}，不过$unwind后的$match无法直接利用数组索引，所以还是优先优化前置的文档级过滤。

执行计划参考 #

"winningPlan" : {
        "stage" : "LIMIT_SKIP",
        "inputStage" : {
                "stage" : "SORT",
                "sortPattern" : {
                        "_id" : -1,
                        "maxCol" : -1
                },
                "inputStage" : {
                        "stage" : "SUBSCAN",
                        "inputStage" : {
                                "stage" : "HASH_AGGREGATE",
                                "inputStage" : {
                                        "stage" : "SUBSCAN",
                                        "inputStage" : {
                                                "stage" : "PROJECTION",
                                                "inputStage" : {
                                                        "stage" : "COLLSCAN"
                                                }
                                        }
                                }
                        }
                }
        }

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