电商场景MongoDB索引选型：单复合索引vs多复合索引？

核心结论 #

在百万级数据且内存有限的场景下，Option 2是更优的选择，这个结论适用于MongoDB及多数关系型、文档型数据库。

具体分析 #

1. 索引匹配效率对比 #

针对你的四类查询需求，逐一匹配索引逻辑：

• 查询1：按category筛选+createdAt排序：Option2中的{category:1, createdAt:-1}索引可直接覆盖筛选与排序操作，无需额外内存做排序；而Option1的复合索引结构是category->price->createdAt，MongoDB无法跳过中间的price字段直接使用createdAt排序，会触发内存排序（结果集超内存阈值时还会写入磁盘，性能暴跌）。
• 查询2：按category筛选+price排序：Option2的{category:1, price:-1}完美匹配需求，直接走索引过滤+排序；Option1的复合索引虽包含这两个字段，但冗余的createdAt字段会增大索引体积，浪费内存。
• 查询3：无category筛选+createdAt排序：Option2的{createdAt:-1}单字段索引直接适配；Option1的复合索引前缀为category，无法用于无category的查询，只能全表扫描后排序，完全不适用。
• 查询4：无category筛选+price排序：Option2的{price:-1}单字段索引直接匹配；Option1的复合索引同样因前缀限制，无法覆盖这类查询，只能全表扫描。

2. 内存占用考量 #

内存有限场景下，索引体积是核心影响因素：

• Option1的复合索引包含三个字段，单条索引条目体积大，百万级数据下整个索引的内存占用极高，大概率无法完全加载到内存，导致频繁磁盘IO，性能急剧下降。
• Option2的四个索引均为针对性小索引：两个复合索引（category+price、category+createdAt）和两个单字段索引，每个索引的体积远小于Option1的大复合索引。MongoDB会优先将常用索引加载到内存，内存利用率更高，不会因单个大索引占用过多内存导致其他索引无法缓存。

3. 其他数据库的适配性 #

无论是MySQL等关系型数据库，还是Elasticsearch等搜索引擎，索引设计逻辑基本一致：

• 复合索引的前缀匹配规则普遍适用，非前缀字段无法用于查询过滤或排序。
• 针对性的小索引比大而全的复合索引更节省内存，且能精准匹配查询需求，避免不必要的索引开销。

补充建议 #

如果你的category是数组类型，MongoDB创建category:1索引时会为数组中每个元素生成索引条目，需注意category的基数（不同类别数量）。即便基数极高，复合索引体积有所增加，Option2仍比Option1更具优势。

内容的提问来源于stack exchange，提问作者Curious Flower