MongoDB 6.0仅timeSeries集合默认启用聚簇索引，按timeField物理排序存储并整合metaField，加速时间范围及元数据查询；普通集合不支持聚簇索引，需依赖复合索引与字段投影优化性能。
时序集合默认启用聚簇索引，但普通集合没有
MongoDB 6.0 的聚簇索引（Clustered Index）仅对 timeSeries 集合自动生效，且不可手动创建或关闭。普通集合（如 users、orders）仍使用传统 B-tree 索引，不支持聚簇索引语义——哪怕你用 createIndex({timestamp: 1}) 加上 {clustered: true} 参数，MongoDB 会直接报错 unrecognized field 'clustered'。
这意味着：如果你的场景是高频按时间范围读写设备传感器数据、日志流或监控指标，应优先建 timeSeries 集合；若只是普通业务文档（比如用户资料），别指望靠“加个 clustered 选项”提速，得回归复合索引 + 字段投影等老办法。
timeSeries 集合的聚簇索引实际怎么起作用
它本质是将文档按 timeField（如 timestamp）物理排序存储，并把元数据字段（如 metaField）也纳入聚簇结构。效果不是“快一点”，而是绕过部分扫描逻辑：
-
last point查询（如找某设备最新一条记录）不再全表扫描，而是直接跳转到物理末尾块 - 按时间范围 + 元数据过滤（如
{meta: {device_id: "d-123"}, timestamp: {$gte: ISODate("...")}}）能利用聚簇顺序做高效 range seek，避免回表 - 排序操作（如
.sort({timestamp: -1}).limit(1)）天然受益，无需额外sort索引
注意：聚簇索引只加速基于 timeField 和 metaField 的查询。如果查的是 status 或 user_id 这类非聚簇字段，性能和普通集合一样，必须另建二级索引。
复合索引仍是主力，尤其在非 timeSeries 场景
即便用了 timeSeries，只要涉及非时间维度的高并发查询（比如“查所有 status=“error” 的设备最近 5 条记录”），就得靠复合索引补位。MongoDB 6.0 对二级索引做了优化，但规则没变：
- 把过滤性最强的字段放前面（如
status比device_id更具区分度，就放左） - 时间字段建议放最后（
{status: 1, device_id: 1, timestamp: -1}），方便范围查询 + 排序复用 - 避免在索引里包含大字段（如长文本、嵌套数组），否则索引体积膨胀，反而拖慢写入
- 用
explain("executionStats")验证是否真正IXSCAN，而不是退化成COLLSCAN
容易被忽略的坑：聚簇 ≠ 自动覆盖，投影仍关键
很多人以为开了 timeSeries 就万事大吉，结果发现慢查询还是多。根本原因是：聚簇索引只决定物理存储顺序，不改变数据返回量。如果一个文档有 50 个字段，而你只需要 timestamp 和 value，却用 find({}) 全量返回，网络和内存开销照样大。
务必配合字段投影：
db.metrics.find(
{ meta: { device_id: "d-123" }, timestamp: { $gte: ISODate("2026-04-14") } },
{ _id: 0, timestamp: 1, value: 1 }
)
否则再好的聚簇和索引，也救不了带宽和序列化瓶颈。
