仅含2个可选值的字段需创建何种索引？现有性别字段索引配置是否够用？

1. 仅存在2个可选值的字段适合创建哪种类型的索引？ #

这类属于典型的低基数字段，索引选型需要结合实际查询场景判断：

• 如果你只会针对该字段过滤占比极低的某一个可选值（比如两个可选值占比为99%和1%，仅查询占比1%的那部分数据），普通单键B树索引就可以满足需求
• 如果该字段经常和其他字段搭配做过滤、排序，更推荐创建复合索引，把该字段放在复合索引的合适位置，能大幅提升索引利用率
• 如果你仅需要固定查询某一个可选值的对应数据，还可以选择部分索引（Partial Index），只索引你需要查询的那个值的对应文档，能大幅减少索引占用的存储空间，降低写入性能损耗

注意：如果两个可选值的占比都接近50%，单独为该字段建索引的收益极低，大部分场景下查询优化器会直接选择全表扫描而非走索引，还会额外占用存储空间、拖慢写入效率，这种场景不建议单独为该字段建索引。

2. 给出的Mongoose配置是否足以在gender字段上创建索引？ #

给出的配置：

var User = new Schema({
    gender: { type: String, index: true }
})

完全可以在gender字段上创建普通单键B树索引，只要应用启动时Mongoose的自动索引功能没有被关闭，该索引就会自动在MongoDB中完成创建。
但要注意：这个索引的实际查询收益还是要结合上述低基数字段的适用场景判断，如果不符合索引生效的查询场景，该索引属于无效冗余索引。

3. 为什么不选择使用sparse（稀疏）索引？ #

稀疏索引的核心特性是只会包含存在该字段、且字段值不为null的文档，不会收录没有该字段或者字段值为null的文档，选择不用它的原因主要有两个：

• 绝大多数场景下gender字段是每个用户文档都存在的必填字段，此时稀疏索引和普通单键索引的存储空间占用几乎没有区别，完全没有使用稀疏索引的必要性
• 如果你后续有查询gender为null、或者没有gender字段的文档的需求，稀疏索引完全无法覆盖这类查询，会直接触发全表扫描，反而会带来查询性能问题

只有当你的业务场景中绝大多数文档都没有gender字段，且你只会查询存在gender字段的文档时，才适合选择稀疏索引。

内容的提问来源于stack exchange，提问作者Bear Bile Farming is Torture