Et par nøglepunkter fra forklaringsplanens output:
- Forespørgslen adresserer følgende attributter:
siteId, status, creationDate, reportCount, assignee, parent - Vinderplanen har to faser:
- IX_SCAN bruger
creationDate_1_reportCount_1_label_1, dette bruger indekserede opslag påcreationDateogreportCountat identificere 56 dokumenter, som derefter videresendes til FETCH-stadiet - FETCH modtager 56 dokumenter fra IX_SCAN-stadiet og udspørger derefter disse dokumenter for at anvende
siteId,status,assigneeogparentfiltre. Denne forespørgsel forårsager, at 37 dokumenter kasseres, hvilket resulterer i, at 19 dokumenter skal returneres.
- IX_SCAN bruger
Så dit indeks dækker kun 2 af de 6 attributter i din forespørgsel, og de resterende 4 attributter i din forespørgsel anvendes ved at undersøge dokumenterne ikke indekset . Hvis du ønsker, at denne forespørgsel skal være fuldt indekseret, skal du oprette følgende indeks:
db.collection.createIndex(
{siteId: 1, status: 1, creationDate: 1, reportCount: 1, assignee: 1, parent: 1}
)
Hvis du kører igen med dette indeks på plads, bør du opdage, at (a) MongoDB vælger dette indeks, og (b) antallet af dokumenter, der videresendes af IX_SCAN-stadiet, er det samme som antallet af dokumenter, der returneres af dit find-opkald.
Jeg siger "skal finde" fordi der er andre aspekter her som kan resultere i at MongoDB vælger et andet indeks f.eks. brug af $nor og sorteringsstadiet (creationDate: 1 ). Jeg vil anbefale at justere indekset og køre med forklaring 'on' efter hver tweak og se efter disse nøgleelementer i executionStats underdokument:
- "nReturneret"
- "totalKeysExamined"
- "totalDocsExamined"
En simpel tommelfingerregel er denne:jo tættere på totalKeysExamined er at nReturned og jo nærmere totalDocsExamined er til nul ... jo bedre din indeksdækning.
Der er også spørgsmålet om omkostningerne ved et indeks (i form af indvirkning på skrivetider og indekslagring), så jeg vil foreslå, at du overvejer dine ikke-funktionelle krav - kan dine ønskede forløbne tider opnås uden fuld indeksdækning? Hvis ikke, bør du fortsætte med empirisk test, men vær parat til at justere dit valg som svar på, hvad explain() output fortæller dig.