El optimizador de consultas de MongoDB funciona probando diferentes planes para determinar qué enfoque funciona mejor para una consulta determinada. El plan ganador para ese patrón de consulta se almacena en caché para las próximas 1000 consultas o hasta que realice una explain() .
Para comprender qué planes de consulta se consideraron, debe usar explain(1) , por ejemplo:
db.col.find({category:'A'}).sort({updated: -1}).explain(1)
Los allPlans detail mostrará todos los planes que se compararon.
Si ejecuta una consulta que no es muy selectiva (por ejemplo, si muchos registros coinciden con sus criterios de {category: { $ne:'A'}} ), puede ser más rápido para MongoDB encontrar resultados usando un BasicCursor (exploración de tabla) en lugar de compararlos con un índice.
El orden de los campos en la consulta generalmente no hace una diferencia para la selección del índice (hay algunas excepciones con consultas de rango). El orden de los campos en un sort afecta la selección del índice. Si su sort() el criterio no coincide con el orden del índice, los datos de resultados deben reordenarse después de usar el índice (debería ver scanAndOrder:true en la salida de explicación si esto sucede).
También vale la pena señalar que MongoDB solo usará un índice por consulta (con la excepción de $or s).
Entonces, si está tratando de optimizar la consulta:
db.col.find({category:'A'}).sort({updated: -1, rating: -1})
Deberá incluir los tres campos en el índice:
db.col.ensureIndex({category: 1, updated: -1, rating: -1})
FYI, si desea forzar una consulta en particular para usar un índice (generalmente no es necesario o recomendado), hay un hint() opción que puedes probar.
