MongoDB复合索引设计：hidden过滤与created_at排序场景方案咨询

问题1：索引合理性评估 #

你定义的{ hidden: 1, created_at: 1 }复合索引完全适配你的业务场景，是当前需求下的最优解，MongoDB可以完美使用该索引执行查询，原因如下：

• 你的查询第一步是精准匹配hidden: false的固定值，索引前缀用hidden可以直接过滤掉占比99%的无用隐藏文档，完全避免全表扫描，过滤效率极高。
• 索引后缀的created_at: 1正好和你升序排序的需求对齐，MongoDB可以直接从索引中读取已经排好序的结果，不需要在内存中执行额外排序操作，也不会触发MongoDB内存排序的32MB上限限制。
• 如果你的查询仅返回hidden、created_at两个字段，该索引还可以触发索引覆盖逻辑，连读取实际文档的步骤都可以省略，性能进一步提升。

问题2：降序排序的索引适用性 #

在你的业务场景下（查询始终携带hidden字段的等值过滤条件），不需要额外创建{hidden: 1, created_at: -1}的索引，原有索引可以同时支持created_at升序、降序两种排序需求。
你了解的单列索引支持正反排序的特性，在当前复合索引场景下仍然生效：当你已经通过hidden: false固定了索引前缀的取值，MongoDB只需要按逆序遍历该前缀下的created_at索引条目，即可得到降序排序的结果，不需要额外做内存排序。
只有当你的查询取消了hidden等值过滤条件、或者需要对多个非等值过滤的索引字段做混合方向排序时，才需要创建对应排序方向的复合索引。

内容的提问来源于stack exchange，提问作者Some Guy