MongoDB 内容后台索引应该怎么补
· 阅读需 2 分钟
MongoDB 在内容后台里确实灵活，但灵活不代表可以把性能问题留到最后再看。很多团队到 2021 年已经用 MongoDB 跑了不短时间，真正感受到压力的地方，往往不是写入，而是后台列表和搜索接口慢慢变慢。
这时候最值得回头补的一层，就是索引设计。
先看查询路径，再决定索引长什么样
索引不是按字段重要性来加的，而是按查询方式来加的。后台最常见的条件通常包括状态、发布时间、作者、分类、更新时间这些组合，如果只给单字段机械加索引，很多实际查询仍然吃不到好处。
所以我更习惯先把高频查询语句列出来，再反推索引。
列表接口通常优先照顾筛选加排序
内容后台的列表页，经常会出现“按状态筛选，再按发布时间倒序”这种模式。这类接口更适合围绕筛选字段和排序字段做复合索引，而不是只给 publishedAt 单独加一个索引就结束。
索引的价值，是服务真实列表模式，不是形式上“字段都有照顾到”。
稀疏或部分索引有时比全量索引更合适
有些字段只在已发布内容、已审核内容里才有意义。如果所有文档都纳入索引，不仅体积更大，收益也未必高。对这类场景，部分索引往往更划算。
内容系统的数据分布本来就不总是均匀的，索引也不必假装它们完全一致。
索引补得越多，不代表越安全
每多一个索引，写入成本和维护成本都会增加。尤其内容后台经常伴随批量导入、批量发布、定时更新，过多索引会把写路径拖慢。
真正成熟的做法，是接受“索引是有代价的”，然后只给高价值查询保留位置。
小结
MongoDB 的索引策略，本质上是在给后台真实查询让路。只要先看查询路径，再围绕筛选和排序补复合索引，内容后台的大部分慢列表问题都能明显缓解。