MongoDB 5.3 并无“列式索引”或“列式压缩”，其索引仍为 B-tree 结构，增强仅体现在索引构建并发性、自动重试、内存控制及 zstd 压缩支持等运维层面优化。
MongoDB 5.3 并未引入“列式压缩”——这是常见误解。WiredTiger 引擎本身支持字典编码、前缀压缩和 LZ4 压缩，但这些属于存储层通用机制，不是 5.3 新增的“列式”特性；官方文档与 release notes 中也无 columnar、column-store 或类似术语。所谓“索引增强”，实际集中在索引构建行为与并发控制层面，而非结构或压缩方式的根本改变。
为什么你查不到 MongoDB 5.3 的“列式索引”？
因为根本不存在。MongoDB 所有版本（包括 5.3）的索引均为 B-tree 结构，按字段值 + 文档 _id 构建有序映射，不按列组织数据块，也不支持跳过无关列的读取。所谓“列式”常被误用于描述：
– Atlas Search 的倒排索引（底层是 Lucene，与原生索引分离）
– Vector Search 的向量索引（使用 HNSW 或 IVF，同样独立于 WiredTiger）
– 用户自行导出到 Snowflake/BigQuery 后做的列存分析
这些都不是 MongoDB Server 端的原生索引能力。
createIndex 在 5.3 中的并发与构建行为变化
5.3 对索引构建过程做了关键优化，主要影响后台建索引时的可用性：
- 默认启用
background: true行为等效性：即使不显式指定，新集合上的首个索引创建也不会完全阻塞写入（相比 4.4 及更早版本的严格前台锁） -
indexBuildRetry自动重试逻辑更鲁棒：当因节点选举、网络分区导致建索引中断时，重启后能从断点继续，而非回滚重来 - 内存使用更可控：对超大集合建复合索引时，5.3 会分批次加载排序键，降低
OutOfMemoryError风险（尤其在mongod内存配额紧张时）
示例：在 10 亿文档集合上执行
db.logs.createIndex({ level: 1, timestamp: -1, service: 1 }, { background: true })
在 5.3 中比 4.4 更大概率成功完成，且期间 insert 和 update 操作延迟波动更小。
真正影响索引效率的 5.3 相关配置项
这些不是“新索引类型”，但会改变索引的实际表现：
-
wiredTigerEngineConfigString中新增index_page_max=64KB（默认值），可手动调小以提升高并发小查询的缓存局部性（但会增加树高度） -
storage.wiredTiger.collectionConfig.blockCompressor支持zstd（需 5.3+ 且 WiredTiger ≥ 10.0.0）：对索引文件本身启用更高压缩比，节省磁盘空间，但 CPU 开销略升 -
setParameter indexBuildRetry=true已成为默认，无需手动开启；若关闭，建索引失败将直接报错退出
注意：zstd 压缩只作用于索引数据块的持久化存储，不影响查询时的内存解压路径或 B-tree 遍历逻辑。
容易忽略的一点：5.3 没有放宽任何索引限制——复合索引仍限 32 字段，$text 索引仍不能和 $near 共存，_id 索引依然不可删。所谓“增强”，是让已有索引机制跑得更稳、更省资源，而不是支持新玩法。
