MongoDB 6.0 不支持列式存储或列式压缩，仍为纯文档型（行式）存储；空间优化依赖 WiredTiger 压缩算法（如 zstd）与精简文档建模，分析型查询应优先优化索引、聚合管道和字段裁剪。
列式压缩在 MongoDB 6.0 中并不存在
MongoDB 6.0 不支持列式存储或列式压缩。它仍是纯文档型（行式）存储引擎，底层 WiredTiger 使用的是基于 B+ 树 + LSM 混合结构的 wiredTiger 引擎，所有字段都随文档一起持久化，无法像 ClickHouse 或 Apache Parquet 那样按列独立编码、压缩或跳过扫描。
所谓“列式压缩提升分析型查询”是常见误解——MongoDB 的分析能力依赖索引覆盖、聚合管道优化和内存映射，而非列存特性。强行套用列式思路反而会导致设计偏差。
真正有效的空间压缩手段：wiredTiger 配置与文档建模
MongoDB 6.0 空间优化完全落在 wiredTiger 引擎层，核心是压缩算法选择与文档结构精简：
-
wiredTiger默认启用snappy压缩（平衡速度与率），生产环境可改用zlib（更高压缩比，CPU 开销上升）或zstd（6.0+ 支持，推荐，压缩率/速度更优）；需在启动时通过--wiredTigerCollectionBlockCompressor=zstd或配置文件中storage.wiredTiger.collectionConfig.blockCompressor设置 - 避免冗余字段：
_class、createdAt/updatedAt等若非必需，删除可显著降低集合体积；WiredTiger 对重复字符串（如状态枚举值"active"、"inactive"）有字典压缩，但字段名本身不压缩，所以短字段名（st代替status）仍有空间收益 - 慎用嵌套过深或超大数组：单文档超过 16MB 会直接写入失败；即使未超限，大数组也会阻碍
$elemMatch索引效率，并增加内存压力
分析型查询慢？先检查是否误用了文档模型
如果目标是高频扫描、聚合、范围过滤（如“近 30 天订单按地区汇总”），MongoDB 并非最优选。但若必须用，关键不是压缩，而是让查询避开全文档解压和遍历：
- 使用
$project提前裁剪字段，尤其排除大文本、二进制（BinData）或长数组字段，减少网络传输与内存占用 - 确保
$match尽可能前置，配合支撑索引（例如{ createdAt: 1, region: 1 }）；否则即使启用了zstd，也要先解压全部文档才能过滤 - 避免在聚合中对未索引字段做
$group或$sort，这会触发内存sort，甚至errmsg: "Sort exceeded memory limit"
什么情况下该考虑替代方案？
当出现以下任一情况，说明 MongoDB 正在被用于它不擅长的场景：
- 单集合数据量 > 1TB 且每日新增 > 50GB，同时需要秒级响应的多维分析（如 OLAP 场景）
- 查询中频繁出现
{ field: { $in: [...] } }匹配数百上千个值，且field无索引或基数极高 - 运维发现
db.serverStatus().metrics.document中return明显高于deleted+inserted，说明大量读取是为丢弃（典型分析扫描特征）
此时应评估导出至 ClickHouse（实时同步 via Kafka + Debezium）、或用 mongodump + mongoexport 定期归档到 Parquet + Trino 架构——不是 MongoDB 不够好，而是模型错配。
