背景

預先建立了一個複合索引，分別以 updated_at 和 size 兩個欄位作為索引依據，其中該collection有94萬+個document

db.cms_resources.createIndex({updated_at:-1,size:-1},{name:'index_updated_size_desc'});

實驗

開始查詢並輸出狀態資訊：

db.cms_resources.find({updated_at:{$lt:1531732138}}).explain(true);

查詢策略使用 IXSCAN 這個沒毛病

但這次查詢按照size欄位條件

db.cms_resources.find({size:{$gt:1}}).explain(true);
 

查詢的策略卻為COLLSCAN全表查詢：

從上面看，好像跟查詢的欄位順序是有關係的，驗證一下，這次把兩個條件updated_at和size都查詢，但位置跟複合索引欄位位置換一下：

db.cms_resources.find({size:{$lt:1},updated_at:{$gt:1}}).explain(true);

返回狀態資訊，還是使用了索引策略

結論

1. 建立複合索引，索引中兩欄位前後順序與查詢條件欄位在數量一致的情況下，順序不影響使用索引查詢。

2.當複合索引中的欄位數量與查詢條件欄位數量不一致情況下，以複合索引欄位前置優先規則。