关于MongoDB普通索引、稀疏索引存储冗余问题的技术咨询

嘿，我来帮你把这个问题拆解清楚~

1. _id索引的强制特性 #

MongoDB会自动为每个文档生成唯一的_id字段，并且默认创建一个覆盖所有文档的_id_索引——这是MongoDB的硬性规则，因为_id是文档的唯一标识，数据库需要通过它来定位、管理所有文档，不管你有没有其他字段，所有文档都会在这个索引里有对应的条目，所以它的存储空间和集合的总文档数直接相关，这也是你看到_id索引大小和x_1接近的原因之一。

2. 普通索引（x_1）的行为逻辑 #

普通索引和稀疏索引的核心区别在于：普通索引会为集合中的所有文档创建索引条目，哪怕文档没有对应的索引字段。
你后来插入的99个不含x、y的文档，在x_1索引里会被当作x: null来存储索引条目。所以这个索引包含了全部198个文档的条目（99个有x的+99个x为null的），存储空间自然和_id索引差不多。

3. 稀疏索引（y_1）的空间优势 #

稀疏索引的设计就是只包含带有索引字段的文档，只有前99个插入的文档有y字段，所以y_1索引里只有99个条目，对应的存储空间就只有普通索引的一半左右，这和你看到的y_1:16384完全匹配。

4. 为什么查询{z:99}会走COLLSCAN #

因为你没有在z字段上创建任何索引，MongoDB找不到可以加速这个查询的索引结构，只能通过全集合扫描（COLLSCAN）来逐个检查文档的z字段值。如果想优化这个查询的性能，给z字段创建一个索引就可以了。

关于“存储空间浪费”的补充 #

其实这是不同索引类型的设计目的决定的：

• 普通索引（比如x_1）的存在是为了支持包含x: null的查询场景，确保所有文档都能被索引覆盖；
• _id索引是MongoDB的基础依赖，无法省略；
• 稀疏索引则是为了在明确不需要索引无字段文档的场景下，节省存储空间。

根据你的业务需求选择合适的索引类型就好啦~

内容的提问来源于stack exchange，提问作者Ns Kumar