Pourquoi MongoDB ne peut pas utiliser un index composé qui est très similaire(pas exact) à la requête?
d'Envisager le dessous de Mongo de l'indice de stratégie et de la requête,
Indice:
db.collec.ensureIndex({a:1,b:1,c:1});
Requête:
db.collec.find({"a":"valueA"},{"_id":0,"a":1,"c":1}).sort({"c":-1}).limit(150)
L'expliquer sur la requête ci-dessus retourne:
/* 0 */
{
"cursor" : "BtreeCursor a_1_b_1_c_1",
"isMultiKey" : false,
"n" : 150,
"nscannedObjects" : 178,
"nscanned" : 178,
"nscannedObjectsAllPlans" : 279,
"nscannedAllPlans" : 279,
"scanAndOrder" : true,
"indexOnly" : true,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 1,
"indexBounds" : {
"a" : [
[
"valueA",
"valueA"
]
],
"b" : [
[
{
"$minElement" : 1
},
{
"$maxElement" : 1
}
]
],
"c" : [
[
{
"$minElement" : 1
},
{
"$maxElement" : 1
}
]
]
}
}
la question ici est
Il est clairement indiqué que la requête tourne complètement sur Index(comme "indexOnly" : true ).
Mais pourquoi le "scanAndOrder" : true
Selon le modèle d'indice Btree, c est à la queue de l'indice pour qu'il puisse être utilisé pour trier. Pas?
pourquoi ne pas l'utiliser?
2 réponses
c'est correct et aussi documentée .
quant au pourquoi: l'index ressemble essentiellement à cet arbre:
- a: "valeur A"
- B:" ABC"
- C: 435
- C: 678
- B: "BCD"
- C: 123
- C: 993
- B:" ABC"
comme vous pouvez le voir, l'ordre est correct et ascendant, mais si vous prenez les valeurs de c dans l'ordre sans limiter à un sous-ensemble de fixe b , vous obtiendrez [435, 678, 123, 993] , qui n'est pas correct, donc scanAndOrder est nécessaire.
malheureusement, les index sans intersectioning sont très rigides.