L'optimiseur de requête MongoDB fonctionne en essayant différents plans pour déterminer quelle approche fonctionne le mieux pour une requête donnée. Le plan gagnant pour ce modèle de requête est ensuite mis en cache pour les ~ 1 000 prochaines requêtes ou jusqu'à ce que vous fassiez un explain() .
Pour comprendre quels plans de requête ont été pris en compte, vous devez utiliser explain(1) , par exemple :
db.col.find({category:'A'}).sort({updated: -1}).explain(1)
Les allPlans détail affichera tous les plans qui ont été comparés.
Si vous exécutez une requête peu sélective (par exemple, si de nombreux enregistrements correspondent à vos critères de {category: { $ne:'A'}} ), il peut être plus rapide pour MongoDB de trouver des résultats à l'aide d'un BasicCursor (balayage de table) plutôt que de faire correspondre un index.
L'ordre des champs dans la requête ne fait généralement pas de différence pour la sélection d'index (il y a quelques exceptions avec les requêtes de plage). L'ordre des champs dans un tri affecte la sélection de l'index. Si votre sort() les critères ne correspondent pas à l'ordre de l'index, les données du résultat doivent être retriées après l'utilisation de l'index (vous devriez voir scanAndOrder:true dans la sortie d'explication si cela se produit).
Il convient également de noter que MongoDB n'utilisera qu'un seul index par requête (à l'exception de $or s).
Donc, si vous essayez d'optimiser la requête :
db.col.find({category:'A'}).sort({updated: -1, rating: -1})
Vous voudrez inclure les trois champs dans l'index :
db.col.ensureIndex({category: 1, updated: -1, rating: -1})
Pour votre information, si vous souhaitez forcer une requête particulière à utiliser un index (généralement non nécessaire ou recommandé), il existe un hint() option que vous pouvez essayer.
