MongoDB 6.0 不支持自动降采样或多粒度缩放，granularity仅影响写入时的物理分桶，不可变且不改变查询精度；多粒度统计必须通过$ dateTrunc + $group实时聚合或预计算物化视图实现。
MongoDB 6.0 本身不提供内置的自动降采样（downsampling）功能，也不支持“多粒度缩放”意义上的动态粒度切换——比如查询时自动从秒级数据聚合出分钟级或小时级视图。所谓“多粒度缩放”，在 MongoDB 中必须由应用层显式建模或借助聚合管道实现，时序集合（timeSeries）只是优化了原始高频数据的存储与基础查询效率。
时序集合的 granularity 是写入期固定的分桶策略，不是查询期可变的缩放参数
granularity（如 "seconds"、"minutes"、"hours"）仅控制 system.buckets 中原始数据的物理分组边界，影响的是磁盘布局和插入/范围扫描性能，**不影响查询结果的精度或粒度**。一旦集合创建，granularity 就不可更改；它也不是“缩放开关”，不能让同一个集合同时返回秒级原始值和小时级平均值。
- 设为
"seconds"：适合每秒写入多个点的传感器流，system.buckets按秒切分，单桶内最多存该秒所有测量值 - 设为
"hours"：适合低频写入（如每小时一个读数），减少桶数量，但会弱化秒级时间戳的查询精度（因时间字段被对齐到小时边界） - 错误认知：“把 granularity 设成 minutes 就能直接查出分钟级均值”——实际仍需用
$group显式聚合
真正的“多粒度”必须靠聚合管道 + 预计算视图组合实现
要在 MongoDB 中支撑类似“缩放”的交互体验（例如前端滑动时间粒度条，后端返回对应粒度的统计），有且仅有两种可行路径：
- 实时聚合：每次查询都走
$dateTrunc（6.0+ 支持）+$group，例如按分钟截断时间并求平均：[{ $dateTrunc: { date: "$timestamp", unit: "minute" } }, { $group: { _id: "$_id", avg: { $avg: "$value" } } }]——适合低并发、中小数据量，但高频率或大数据集下延迟明显 - 预计算物化视图：用定时任务（如 Atlas Scheduled Triggers 或外部 cron）将原始时序集合按不同粒度（1min / 5min / 1h / 1d）聚合写入独立集合，查询时直读对应视图——这是生产环境唯一可控的方案
- 注意：6.0 的
bucketMaxSpanSeconds和bucketRoundingSeconds（6.3+ 引入）仅用于微调桶边界对齐，不改变数据语义，也不能替代聚合逻辑
容易踩的坑：误以为索引能加速任意粒度聚合
即使你在时序集合上建了 { timestamp: 1, metadata: 1 } 复合索引，$dateTrunc + $group 依然大概率触发全桶扫描——因为 $dateTrunc 不是索引可下推操作符。MongoDB 6.0 对 last-point 查询做了优化，但对任意时间窗口的聚合没有特殊加速机制。
- 验证方式：用
explain("executionStats")查看nReturned与totalDocsExamined是否接近；若后者远大于前者，说明索引未有效裁剪数据范围 - 真正有效的索引策略：在预计算视图上建
{ truncatedTime: 1, seriesId: 1 }，让聚合结果本身可索引 - 不要依赖
granularity值来“节省空间”——它只影响桶结构，压缩比主要取决于实际写入密度和字段冗余度
核心要记住：MongoDB 的时序能力是“高效存、快读原始点”，不是“自动管、智能缩放”。多粒度需求的本质是 OLAP 场景，而 MongoDB 仍是 OLTP 底座。把降采样逻辑交给应用或预计算层，比强求数据库做它不擅长的事更可靠。
