百万级文档中含嵌套字段的复合索引：多键弊端及结构差异咨询

一、复合索引{ _id: 1, Title: 1, Scheduling.From: 1 }的潜在性能问题 #

• 索引冗余与额外开销：MongoDB默认会为_id创建唯一单键索引，将_id作为复合索引的首字段属于冗余设计：
  • 当查询条件包含_id时，默认的_id索引足以提供最优查询性能，额外维护这个复合索引只会增加写入时的索引更新开销，同时占用更多磁盘存储空间。
  • 当查询条件不包含_id时，由于复合索引的前缀匹配规则，该索引无法被用于仅基于Title、Scheduling.From或两者组合的查询，这类查询只能走全表扫描或其他合适的索引。
• 字段顺序限制索引适用性：复合索引的字段顺序直接决定了它能支持的查询类型。如果你的业务查询大多以Title或Scheduling.From作为过滤前缀，当前的索引顺序完全无法匹配这类场景，复合索引的优势无法发挥。
• 无多键索引风险：由于Scheduling是单个内嵌文档而非数组，Scheduling.From是单值字段，该索引不属于多键索引，因此不会遇到多键索引相关的性能问题（如基数膨胀、索引组合限制等）。

二、两种文档结构的索引表现差异 #

首先必须明确：MongoDB禁止字段名称包含.字符，因为.是MongoDB用于访问内嵌文档的保留语法。你给出的第二种“扁平化嵌套字段”结构（字段名为Scheduling.From）是非法的，无法插入到集合中，因此不存在同一索引下的性能对比基础。

如果你的实际需求是将内嵌字段提升为顶层字段（例如将Scheduling.From更名为SchedulingFrom），那么：

• 若对应调整索引为{ _id: 1, Title: 1, SchedulingFrom: 1 }，其性能表现与原内嵌字段的复合索引几乎无差异。MongoDB索引引擎对单值顶层字段和单值内嵌字段的处理逻辑一致，查询、写入的性能差距可以忽略。

内容的提问来源于stack exchange，提问作者Roberto Montalti