Mongo-datumbereikindex met filters

Een paar belangrijke punten uit de uitvoer van het plan uitleggen:

• De query heeft betrekking op de volgende attributen:siteId, status, creationDate, reportCount, assignee, parent
• Het winnende plan bestaat uit twee fasen:
  • IX_SCAN gebruikt creationDate_1_reportCount_1_label_1 , dit gebruikt geïndexeerde zoekopdrachten op creationDate en reportCount om 56 documenten te identificeren die vervolgens worden doorgestuurd naar de FETCH-fase
  • FETCH ontvangt 56 documenten van de IX_SCAN-fase en ondervraagt ​​deze documenten vervolgens om de siteId toe te passen , status , assignee en parent filters. Deze ondervraging zorgt ervoor dat 37 documenten worden weggegooid, wat resulteert in 19 documenten die worden geretourneerd.

Uw index dekt dus slechts 2 van de 6 kenmerken in uw zoekopdracht en de overige 4 kenmerken in uw zoekopdracht worden toegepast door de documenten te onderzoeken. niet de index . Als u wilt dat deze zoekopdracht volledig wordt geïndexeerd, maakt u de volgende index:

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

Als u deze index opnieuw uitvoert, zou u moeten constateren dat (a) MongoDB deze index kiest en (b) het aantal documenten dat door de IX_SCAN-fase wordt doorgestuurd, hetzelfde is als het aantal documenten dat wordt geretourneerd door uw zoekaanroep.

Ik zeg "zou moeten vinden" omdat er hier andere aspecten zijn die ertoe kunnen leiden dat MongoDB een andere index kiest, b.v. gebruik van $nor en de sorteerfase (creationDate: 1 ). Ik zou aanraden om de index aan te passen en uit te voeren met 'aan' na elke tweak en te zoeken naar deze belangrijke items in de executionStats subdocument:

• "nReturned"
• "totalKeysExamined"
• "totalDocsExamined"

Een eenvoudige vuistregel is deze:hoe dichter totalKeysExamined is naar nReturned en hoe dichter totalDocsExamined is tot nul ... hoe beter uw indexdekking.

Er is ook de kwestie van de kosten van een index (in termen van impact op schrijftijden en indexopslag), dus ik raad aan om rekening te houden met uw niet-functionele vereisten - kunnen de gewenste verstreken tijden worden bereikt zonder volledige indexdekking? Als dat niet het geval is, moet u empirisch testen, maar wees bereid om uw keuze aan te passen in reactie op wat de explain() uitgang vertelt het je.