MongoDB复合索引中1与-1的区别解析及使用疑问

一、{userid: 1, score: -1}中1与-1的区别 #

• 1：代表索引按该字段升序存储，即userid的值从小到大排列（如1→2→3...）
• -1：代表索引按该字段降序存储，即score的值从大到小排列（如100→99→98...）
• 排序方向直接影响查询的排序效率：如果你的查询需要userid升序、score降序返回结果，这个索引可以直接复用索引的存储顺序返回数据，无需额外排序；但如果查询的排序逻辑和索引完全相反（如userid降序、score升序），索引的排序优势就无法发挥。

二、索引未提升查询速度的常见原因及解决思路 #

1. 查询未命中索引 #

• 未使用索引前缀：复合索引遵循前缀匹配规则，如果你的查询只过滤score（如db.collection.find({score: 90})），未用到前缀字段userid，该复合索引不会被触发
• 索引字段上使用函数/表达式：比如db.collection.find({$expr: {$gt: ["$userid", 100]}})或db.collection.find({userid: {$mod: [5, 0]}})，这类操作会让MongoDB无法直接利用索引，只能全表扫描
• 字段类型不匹配：若索引中userid是数字类型，但查询时传入字符串（如db.collection.find({userid: "100"})），类型转换会导致索引失效

2. MongoDB主动放弃使用索引 #

当查询返回的结果集占集合总数据的20%-30%以上时，MongoDB会判定全表扫描比索引查询更高效，自动跳过索引。这种情况可以：

• 优化查询条件，缩小结果范围
• 用hint()强制指定索引（如db.collection.find({userid: 10}).hint({userid:1, score:-1})），但需测试验证是否真的提升性能

3. 索引设计不合理 #

• 字段顺序错误：如果高频查询是按score过滤、userid排序，当前的{userid:1, score:-1}索引就不匹配，应调整为{score:1, userid:-1}
• 存在冗余索引：若已创建{userid:1}单字段索引，再建{userid:1, score:-1}复合索引会冗余，增加写入时的索引维护成本，反而拖慢性能

4. 排查工具使用 #

用explain("executionStats")分析查询执行计划：

db.collection.find(/* 你的查询条件 */).explain("executionStats")

查看executionStats.executionStages.inputStage.stage字段：

• IXSCAN：表示查询命中了索引
• COLLSCAN：表示执行了全表扫描，索引未生效

内容的提问来源于stack exchange，提问作者Rishikesh mahajan