MongoDB时序数据库重建后查询异常缓慢求助

核心问题根源 #

你遇到的慢查询本质是时序集合（Timeseries Collection）的桶存储特性未被正确利用，查询时先解包所有可能的桶再过滤，而非在桶级别提前过滤数据。从你提供的currentOp输出可见，查询执行顺序是先执行$_internalUnpackBucket（解包所有桶），再做$match过滤，这会引发大量无效解包操作，数据量越大性能下降越明显。

另外，你创建的索引未适配底层桶结构：MongoDB时序集合的底层数据存在system.buckets.<collectionName>集合中，直接在时序集合上创建的索引会被映射为桶文档control字段的索引，但你的索引定义未配合查询的过滤+排序逻辑，导致查询优化器无法高效利用索引。

具体修复步骤 #

1. 重建适配时序桶的复合索引 #

删除现有两个索引，创建带排序方向的复合索引，匹配查询过滤条件+数据获取需求（取最新1000条数据）：

// 在时序集合上执行
db.MyTS.createIndex({asset: 1, measurement: 1, timestamp: -1})

该索引会被MongoDB自动转换为底层桶集合的索引：

{
  "control.min.asset": 1,
  "control.max.asset": 1,
  "control.min.measurement": 1,
  "control.max.measurement": 1,
  "control.max.timestamp": -1
}

此索引可让MongoDB在桶级别就过滤掉不匹配asset和measurement的桶，同时通过timestamp降序排序快速定位最新的1000条数据，避免全桶解包。

2. 调整查询逻辑，添加排序 #

你的查询未指定排序方向，MongoDB默认按磁盘存储顺序返回数据，即使有索引也需扫描大量匹配文档才能取到1000条。修改Rust代码，添加timestamp降序排序：

let doc = doc!{
    "asset": asset,
    "measurement": measurement
};
let find_options = FindOptions::builder()
    .projection(doc! {
        "timestamp": 1,
        "data": 1,
    })
    .sort(doc!{"timestamp": -1}) // 新增排序，匹配索引方向
    .limit(1000)
    .build();
let res = coll.find(doc, find_options).await.unwrap();

排序与索引方向一致时，MongoDB可直接通过索引遍历拿到前1000条数据，无需扫描额外文档。

3. 验证查询计划 #

用explain命令验证索引是否被正确使用，确保查询在桶级别过滤：

db.MyTS.find({asset:"my_asset", measurement:"price"})
  .projection({timestamp:1, data:1})
  .sort({timestamp:-1})
  .limit(1000)
  .explain("executionStats")

查看executionStats中的executionStages，确认第一阶段是IXSCAN针对底层桶的control字段索引，之后才是$_internalUnpackBucket，且nReturned与totalDocsExamined数值接近，说明无无效扫描。

4. 排查TTL自动删除的影响 #

开启自动删除（TTL）的时序集合会自动创建TTL索引，需确保TTL索引字段为timestamp，且与查询索引无冲突。如果TTL删除操作与查询操作竞争资源，可通过setParameter调整ttlMonitorSleepSecs参数，调整TTL删除频率，避免业务高峰时执行大量删除操作。

额外注意事项 #

• 无需同时创建{measurement:1, asset:1, timestamp:1}和{asset:1, measurement:1, timestamp:1}，MongoDB可根据查询条件选择合适的前缀索引，针对你的核心查询，{asset:1, measurement:1, timestamp:-1}已足够覆盖。
• 避免在时序集合上创建过多索引，会增加写入开销，尤其每月5GB的写入量下，过多索引会导致写入性能下降。

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