Problém je v tom, že žádný z vašich indexů ve skutečnosti nepomáhá s tříděným dotazem. To je důvodem vysokého počtu skenovaných objektů a přítomnosti SORT_KEY_GENERATOR
fáze (třídění v paměti, omezeno na 32 MB).
Netříděný dotaz na druhou stranu může používat buď { category: 1, _id: 1 }
nebo { category: 1, _id: 1, sticky: 1, lastPostAt: 1 }
indexy. Všimněte si, že je naprosto správné použít kterýkoli z nich, protože jeden obsahuje prefix toho druhého. Další podrobnosti naleznete v části Předpony.
MongoDB find()
dotazy obvykle používají pouze jeden index, takže jeden složený index by měl pokrýt všechny parametry vašeho dotazu. To by zahrnovalo oba parametry find()
a sort()
.
Dobrý zápis o tom, jak by měl být váš index vytvořen, je k dispozici v Optimalizaci složených indexů MongoDB. Vezměme hlavní bod článku, kde by řazení složeného indexu mělo být rovnost --> řazení --> rozsah :
Váš dotaz "shape" je:
db.collection.find({category:..., _id: {$gt:...}})
.sort({sticky:-1, lastPostAt:-1, _id:1})
.limit(25)
Vidíme to:
category:...
je rovnoststicky:-1, lastPostAt:-1, _id:1
je seřadit_id: {$gt:...}
je rozsah
Takže složený index, který potřebujete, je:
{category:1, sticky:-1, lastPostAt:-1, _id:1}
Kde je vítězný plán explain()
výstup vašeho dotazu s výše uvedeným indexem ukazuje:
"winningPlan": {
"stage": "LIMIT",
"limitAmount": 25,
"inputStage": {
"stage": "FETCH",
"inputStage": {
"stage": "IXSCAN",
"keyPattern": {
"category": 1,
"sticky": -1,
"lastPostAt": -1,
"_id": 1
},
"indexName": "category_1_sticky_-1_lastPostAt_-1__id_1",
"isMultiKey": false,
"multiKeyPaths": {
"category": [ ],
"sticky": [ ],
"lastPostAt": [ ],
"_id": [ ]
},
"isUnique": false,
"isSparse": false,
"isPartial": false,
"indexVersion": 2,
"direction": "forward",
"indexBounds": {
"category": [
"[ObjectId('5a779b31f4fa724121265142'), ObjectId('5a779b31f4fa724121265142')]"
],
"sticky": [
"[MaxKey, MinKey]"
],
"lastPostAt": [
"[MaxKey, MinKey]"
],
"_id": [
"(ObjectId('5a779b5cf4fa724121269be8'), ObjectId('ffffffffffffffffffffffff')]"
]
}
}
}
}
Všimněte si, že vítězný plán neobsahuje SORT_KEY_GENERATOR
etapa. To znamená, že index lze plně využít k odpovědi na seřazený dotaz.