MongoDB 7.0 不支持 Columnstore 索引，其 WiredTiger 引擎始终采用行存结构；所谓“列存”实为对 timeseries 集合、索引覆盖查询或第三方工具的误解；正确优化聚合需前置 $match、合理建复合索引、善用 timeseries 及 explain 分析执行计划。
Columnstore索引在MongoDB 7.0中并不存在
MongoDB 7.0 **不支持 Columnstore（列存）索引**。这是常见误解，源于将其他数据库（如PostgreSQL、SQL Server 或 ClickHouse）的特性误迁到 MongoDB。MongoDB 的 WiredTiger 存储引擎始终采用 **行存（row-store）结构**，所有索引（包括复合索引、文本索引、2dsphere 索引等）都是 B-Tree 或 LSM 变种，按文档粒度组织，而非按字段列独立存储。
如果你看到“MongoDB 列存”相关宣传，大概率是混淆了以下概念：
- 时间序列集合（
timeseries）——它通过 bucketing 压缩和按时间范围预聚合提升查询效率，但底层仍是行存，不是列存 - 覆盖查询（
indexOnly: true）——当$project+$match仅涉及索引字段时，WiredTiger 可直接从索引页读取数据，跳过文档解码，这常被误称为“类列存行为”，实则只是索引扫描优化 - 第三方工具或中间件（如 MongoDB Connector for BI）——它们可能在内存中构建列式视图，但非 MongoDB 原生能力
真正能加速聚合统计的原生手段：$match 必须前置 + 复合索引对齐
千万级数据下聚合慢，90% 源于管道顺序错误和索引缺失。以统计高消费用户为例：
db.orders.aggregate([
{ $group: { _id: "$user_id", total: { $sum: "$amount" } } },
{ $match: { total: { $gt: 1000 } } },
{ $sort: { total: -1 } }
])
这个写法会让 MongoDB 先扫全表分组，再过滤，最后排序——完全无法利用索引。
正确做法是：
-
$match尽量提前，最好作为第一个阶段，且条件字段必须有索引 - 若需按
user_id分组并按total排序，应建复合索引：db.orders.createIndex({ user_id: 1, amount: 1 })（注意：不能用amount单独索引，因为$sum不走索引） - 更优解是把过滤逻辑下沉：比如先限定时间范围（
created_at: { $gte: ... }），该字段加在复合索引最前，让$match阶段能快速定位子集 - 避免在
$group后使用$sort；如必须排序，确保_id或分组键本身可排序，或改用$facet+ 内存限制控制
时间序列集合是高频聚合场景的实质加速器
如果你的聚合对象是传感器、日志、监控指标等按时间写入的数据，timeseries 集合比任何“伪列存”都管用。它不是索引类型，而是一种物理存储优化：
- 自动按
granularity（如"minutes"）打包多条记录进单个 bucket 文档，减少 I/O 次数 - 内置时间范围剪枝：查询
{ timestamp: { $gte: ..., $lt: ... } }时，引擎直接跳过无关 bucket，不扫描内部数组 - 聚合时
$group可结合$dateTrunc实现毫秒级对齐，且explain("executionStats")显示totalKeysExamined极低
创建示例：db.createCollection("metrics", { timeseries: { timeField: "ts", metaField: "host", granularity: "minutes" } })
explain 是唯一可信的性能判断依据
别猜，直接看执行计划。运行带 explain: "executionStats" 的聚合：
db.orders.aggregate([...], { explain: "executionStats" })
重点关注三项：
-
nReturned与totalDocsExamined的比值：越接近 1 越好；若后者远大于前者，说明$match没生效或索引未命中 -
totalKeysExamined：应明显小于totalDocsExamined，否则索引未被用于过滤 -
executionTimeMillis和usedDisk：若usedDisk: true，说明$group或$sort内存超限（默认 100MB），需加allowDiskUse: true，但更要检查是否能缩小输入集
最容易被忽略的是：WiredTiger 缓存压力下，即使索引存在，也可能退化为 collection scan。务必同时查 serverStatus().wiredTiger.cache 中的 bytes currently in the cache 和 maximum bytes configured 比值——低于 80% 就意味着热数据反复换入换出。
