Index de plage de dates Mongo avec filtres

Quelques points clés de la sortie du plan d'explication :

• La requête porte sur les attributs suivants :siteId, status, creationDate, reportCount, assignee, parent
• Le plan gagnant comporte deux étapes :
  • IX_SCAN utilise creationDate_1_reportCount_1_label_1 , cela utilise des recherches indexées sur creationDate et reportCount pour identifier 56 documents qui sont ensuite transmis à l'étape FETCH
  • FETCH reçoit 56 documents de l'étape IX_SCAN, puis interroge ces documents pour appliquer le siteId , status , assignee et parent filtres. Cette interrogation entraîne le rejet de 37 documents, ce qui entraîne le retour de 19 documents.

Ainsi, votre index ne couvre que 2 des 6 attributs de votre requête et les 4 attributs restants de votre requête sont appliqués en examinant les documents pas l'index . Si vous souhaitez que cette requête soit entièrement couverte par l'index, créez l'index suivant :

db.collection.createIndex(
    {siteId: 1, status: 1, creationDate: 1, reportCount: 1, assignee: 1, parent: 1}
) 

Si vous exécutez avec cet index en place, vous devriez constater que (a) MongoDB choisit cet index et (b) le nombre de documents transmis par l'étape IX_SCAN est le même que le nombre de documents renvoyés par votre appel de recherche.

Je dis "devrait trouver" car il y a d'autres aspects ici qui pourraient amener MongoDB à choisir un index différent, par ex. utilisation de $nor et l'étape de tri (creationDate: 1 ). Je recommanderais de peaufiner l'index et d'exécuter avec expliquer 'on' après chaque ajustement et de rechercher ces éléments clés dans le executionStats sous-document :

• "nRetourné"
• "totalKeysExamined"
• "totalDocsExamined"

Une règle simple est la suivante :plus totalKeysExamined est proche est à nReturned et plus totalDocsExamined se rapproche est à zéro ... meilleure est la couverture de votre index.

Il y a aussi la question du coût d'un index (en termes d'impact sur les temps d'écriture et le stockage de l'index), je suggérerais donc de prendre en compte vos exigences non fonctionnelles - les temps écoulés souhaités peuvent-ils être atteints sans une couverture complète de l'index ? Si ce n'est pas le cas, vous devez procéder à des tests empiriques, mais soyez prêt à modifier votre choix en réponse à ce que le explain() sortie vous dit.