Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Abfrageplaner v2
Der neue Abfrageplaner für Amazon DocumentDB (Planer-Version 2.0) bietet erweiterte Funktionen zur Abfrageoptimierung und eine verbesserte Leistung. Die Planner-Version 2.0 für Amazon DocumentDB 5.0 bietet eine bis zu 10-fache Leistungsverbesserung gegenüber der Vorgängerversion, wenn Sie update AND-Operatoren mit find Indizes verwenden. Leistungsverbesserungen sind in erster Linie auf die Verwendung optimalerer Indexpläne und die Aktivierung der Unterstützung von Indexscans für Operatoren wie Negationsoperatoren ($neq,$nin) und Nested zurückzuführen. $elementMatch Abfragen von Planner Version 2.0 werden dank besserer Kostenschätzungstechniken, optimierter Algorithmen und verbesserter Stabilität schneller ausgeführt. Planner Version 2.0 unterstützt auch Plan-Cache-Filter-APIs, wodurch die Stabilität des Planers verbessert wird. Mit dieser Funktion bietet Amazon DocumentDB 5.0 jetzt die Möglichkeit, aus den verschiedenen Versionen des Abfrageplaners auszuwählen.
Voraussetzungen
Die folgenden Voraussetzungen gelten für die Planner-Version 2.0:
Planner Version 2.0 ist überall dort verfügbar AWS-Regionen , wo Engine-Version 5.0 verfügbar ist.
Um sich für die Verwendung von Version 2.0 als Standard-Abfrageplaner zu entscheiden, muss Ihr Cluster auf dem Engine-Patch Version 3.0.15902 oder höher der Amazon DocumentDB-Version 5.0 installiert sein. Schritte zur Aktualisierung auf den neuesten Patch für die Engine-Version finden Sie unter. Durchführung eines Patch-Updates für die Engine-Version eines Clusters
Um Planner Version 2.0 als Standard-Abfrageplaner festzulegen, benötigen Sie IAM-Berechtigungen, um Cluster-Parametergruppen zu aktualisieren.
Für Amazon DocumentDB 8.0 ist Planner Version 3.0 der Standard-Abfrageplaner. Details dazu finden Sie unter Abfrageplaner v3.
Auswahl der Planner-Version 2.0 als Standard-Abfrageplaner
Gehen Sie wie folgt vor, um 2.0 in der Konsole oder CLI als Standard-Abfrageplaner auszuwählen:
Folgen Sie den Schritten unterÄnderung der Amazon DocumentDB-Cluster-Parameter, um die Parametergruppe Ihres Clusters zu ändern.
Ändern Sie den Wert für den Parameter mit dem Titel „PlannerVersion“ auf 2.0, was auf die Planerversion 2.0 hinweist.
Wählen Sie Sofort anwenden aus (wenn Sie Beim Neustart anwenden auswählen, wird die Auswahl bis zum nächsten Neustart des Clusters unwirksam).
Bewährte Methoden
Verwenden Sie bei der Anwendung von Planner Version 2.0 die folgenden bewährten Methoden, um die erwarteten Ergebnisse zu erzielen:
Wählen Sie in einem globalen Cluster den gleichen plannerVersion Wert (1,0 oder 2,0) in den Cluster-Parametergruppen für beide Regionen aus. Beachten Sie, dass die Auswahl unterschiedlicher Planerversionen in primären und sekundären Regionen zu einem inkonsistenten Abfrageverhalten und einer inkonsistenten Leistung führen kann.
Die Aktualisierung auf Planner-Version 2.0 während eines geplanten Wartungsfensters oder in Zeiten mit reduziertem Verkehrsaufkommen ist am wenigsten störend, da es zu erhöhten Fehlerraten kommen kann, wenn die Planner-Version geändert wird, während Workloads aktiv ausgeführt werden.
Planner Version 2.0 funktioniert am optimalsten mit der MongoDB-Shell-Version 5.0.
Einschränkungen
Die folgenden Einschränkungen gelten für die Planner-Version 2.0:
Planner-Version 2.0 wird in elastischen Clustern nicht unterstützt. Diese werden auf Planner-Version 1.0 zurückgreifen.
Planner-Version 2.0 wird für Aggregation und unterschiedliche Befehle nicht unterstützt. Diese werden auf Planner-Version 1.0 zurückgegriffen.
Für einige Abfrage-Shapes kann kein Plan-Cache-Filter festgelegt werden. Die aktuelle Liste finden Sie unterUnterstützte Abfrage-Shapes.
Verbesserungen beim Suchen und Aktualisieren von Operatoren
Planner Version 2.0 optimiert grundlegende Operationen wiefind, updatedelete, und find-and-modify Befehle. In den folgenden Abschnitten mit Registerkarten werden die erweiterten Funktionen für Indizes sowie die Verbesserungen der Abfrageleistung mit Planner Version 2.0 beschrieben:
- Enhanced index support
-
Planner Version 2.0 bietet Indexunterstützung für Negationsoperatoren wie $nin$ne, $not {eq}$not {in}, und sowie und und. $type $elemMatch
Sample Document: { "x": 10, "y": [1, 2, 3] }
db.foo.createIndex({ "x": 1, "y": 1 })
db.foo.find({ "x": {$nin: [20, 30] }})
db.foo.find({"x":{ $type: "string" }})
db.foo.createIndex({"x.y": 1})
db.foo.find({"x":{$elemMatch:{"y":{$elemMatch:{"$gt": 3 }}}}})
Planner Version 2.0 verwendet Indizes mit geringer Dichte oder nur teilweise, auch wenn sie im $exists Abfrageausdruck nicht vorhanden sind.
Sample Document: {"name": "Bob", "email": "example@fake.com" }
Using Planner Version 1.0, you can specify the command as shown below:
db.foo.find({email: "example@fake.com", email: {$exists: true}})
Using Planner Version 2.0, you can specify command without $exists:
db.foo.find({ email: "example@fake.com" })
Planner Version 2.0 verwendet Teilindizes auch dann, wenn die Abfragebedingung nicht genau mit dem Filterausdruck für den Teilindex übereinstimmt.
Sample Document: {"name": "Bob", "age": 34}
db.foo.createIndex({"age":1},{partialFilterExpression:{"age":{$lt:50}}})
With Planner Version 1.0, index is used only when the query condition meets the partial
index filter criterion:
db.foo.find({"age":{$lt:50}})
With Planner Version 2.0, index is used even when the query condition doesn’t meet the index
criterion:
db.foo.find({"age":{$lt:30}})
Planner Version 2.0 verwendet einen teilweisen Indexscan mit $elemMatch-Abfragen.
Sample Document: {"name": "Bob", "age": [34,35,36]}
db.foo.createIndex({"age":1},{partialFilterExpression:{"age":{$lt:50,$gt:20}}})
db.foo.find({age:{$elemMatch:{$lt:50,$gt:20}}})
Planner Version 2.0 unterstützt Index-Scans für$regex, ohne dass Sie den Code $hint in Ihrer Anwendung angeben müssen. $regexunterstützt den Index nur bei Präfixsuchen.
Sample Document: { "x": [1, 2, 3], "y": "apple" }
db.foo.createIndex({ "x": 1, "y": 1 })
db.foo.find({"y":{ $regex: "^a" }})
Planner Version 2.0 verbessert die Leistung von Abfragen mit Indizes mit mehreren Schlüsseln, wobei Gleichheitsbedingungen für Felder mit mehreren Schlüsseln gelten.
Sample Document: {"x": [1, 2, 3],
"y": 5}
db.foo.createIndex({"x": 1, "y":1})
db.foo.find({"x": 2,
"y": {$gt: 1}}).limit(1)
Planner Version 2.0 verbessert die Leistung von Abfragen, die mehrere Filter beinhalten, insbesondere bei Sammlungen mit Dokumenten, die größer als 8 KB sind.
Sample Document: {"x": 2,
"y": 4,
"z": 9,
"t": 99}
db.foo.find({$and: [{"x": {$gt : 1}, "y": {$gt : 3}, "z": {$lt : 10},
"t":{$lt : 100}}]})
Planner Version 2.0 verbessert die Leistung von Abfragen, wenn der $in Operator mit einem zusammengesetzten Index verwendet wird, indem die Sortierphase entfällt.
Sample Document: {"x": 2,
"y": 4,
"z": 9,
"t": 99}
db.foo.createIndex({"x":1, "y":1})
db.foo.find({"x":2,
"y":$in:[1,2,3,4]}).sort({x:1,y:1})
Es verbessert auch die Leistung von Abfragen, die Mehrschlüsselindizes mit $in Elementen verwenden.
Sample Document: {"x": [1, 2, 3]}
db.foo.createIndex({"x": 1})
db.foo.find("x":{$in:[>100 elements]})
- Query performance improvements
-
Planner Version 2.0 verbessert die Leistung von Abfragen, die mehrere Filter beinhalten, insbesondere bei Sammlungen mit Dokumenten, die größer als 8 KB sind.
Sample Document: {"x": 2,
"y": 4,
"z": 9,
"t": 99}
db.foo.find({$and: [{"x": {$gt : 1}, "y": {$gt : 3}, "z": {$lt : 10},
"t":{$lt : 100}}]})
Planner Version 2.0 verbessert die Leistung von Abfragen, wenn der $in Operator mit einem zusammengesetzten Index verwendet wird, indem die Sortierphase entfällt.
Sample Document: {"x": 2,
"y": 4,
"z": 9,
"t": 99}
db.foo.createIndex({"x":1, "y":1})
db.foo.find({"x":2,
"y":$in:[1,2,3,4]}).sort({x:1,y:1})
Es verbessert auch die Leistung von Abfragen, die Multikey-Indizes mit $in Elementen verwenden.
Sample Document: {"x": [1, 2, 3]}
db.foo.createIndex({"x": 1})
db.foo.find("x":{$in:[>100 elements]})
Planen Sie Cache-Filter
Planner Version 2.0 bietet Unterstützung für Plan-Cache-Filter, auch Indexfilter genannt, mit denen Sie die Gruppe von Indizes einschränken können, die der Planer für eine bestimmte Abfrageform berücksichtigt. Filter werden mit einem Datenbankbefehl festgelegt und auf den Server angewendet. Wenn Sie also eine Abfrageregression feststellen, können Sie diese abmildern, ohne Ihren Anwendungscode zu ändern.
In der Planner-Version 2.0 gelten Plan-Cache-Filter für die count Befehle find und ab Amazon DocumentDB 5.0.2 und 8.0.2 auch für die update Befehle, und. delete findAndModify Für die aggregate Befehle distinct und ist die Planner-Version 3.0 erforderlich.
Weitere Informationen zur Befehlsreferenz, zu unterstützten Abfrageformen, funktionierenden Beispielen und zur Interaktion von Filtern mit Hinweisen finden Sie unterCache-Filter planen.
Mögliche Verhaltensunterschiede zwischen Planner-Version 1.0, 2.0 und MongoDB
In einigen Randfällen ist es möglich, dass Planner-Version 2.0 Ergebnisse liefert, die leicht von den Ergebnissen in MongoDB abweichen. In diesem Abschnitt werden einige Beispiele für diese Möglichkeiten vorgestellt.
- $(update) and $(projection)
-
In einigen Fällen verhalten sich $(update) $(projection) Operatoren in MongoDB möglicherweise anders als in der Planer-Version 1.0 von Amazon DocumentDB. Im Folgenden finden Sie einige Beispiele:
db.students_list.insertMany( [ { _id: 5, student_ids: [ 100, 200 ], grades: [ 95, 100 ], grad_year: [ 2024, 2023 ] } ] )
db.students_list.updateOne({ student_ids: 100, grades: 100, grad_year: 2024 },
{ $set: { “grad_year.$”: 2025 } }
Planner Version 1.0 — Aktualisiert das Feld 2022
MongoDB — Aktualisiert das Feld 2022
Planner Version 2.0 — Aktualisiert das Feld 2021
db.col.insert({x:[1,2,3]})
db.col.update({$and:[{x:1},{x:3}]},{$set:{"x.$":500}})
Planner Version 1.0 — Aktualisiert nach dem Zufallsprinzip das erste übereinstimmende Element
MongoDB — Aktualisiert nach dem Zufallsprinzip das erste übereinstimmende Element
Planner Version 2.0 — Führt keine Aktualisierungen durch
db.col.insert({x:[1,2,3]})
db.col.find()
Planner Version 1.0 — Wählt das übereinstimmende Element nach dem Zufallsprinzip aus
MongoDB — Wählt das übereinstimmende Element nach dem Zufallsprinzip aus
Planner Version 2.0 — Trifft keine Auswahl
db.col.insert({x:100})
db.col.update({x:100},{x:100})
Planner-Version 1.0 — Änderung der Anzahl der Änderungen
MongoDB — Änderungen an der Anzahl
Planner Version 2.0 — Die Anzahl von nModified ändert sich nicht, wenn sie mit demselben Wert aktualisiert wird.
Wenn der $(update) Operator mit verwendet wird$setOnInsert, geben Planner Version 1.0 und MongoDB einen Fehler aus, Planner Version 2.0 jedoch nicht.
Das Umbenennen eines nicht existierenden Felds in Planner Version 2.0 $field führt zu einem Fehler, während es in Planner Version 1.0 und MongoDB nicht zu Aktualisierungen kommt.
- Index behavior
-
Planner-Version 2.0 gibt einen Fehler aus, wenn sie mit einem ungeeigneten Index angewendet $hint wird, wohingegen Planner-Version 1.0 und MongoDB dies nicht tun.
// Insert
db.col.insert({x:1})
db.col.insert({x:2})
db.col.insert({x:3})
// Create index on x with partialFilter Expression {x:{$gt:2}}
db.col.createIndex({x:1},{partialFilterExpression:{x:{$gt:2}}})
// Mongodb allows hint on the following queries
db.col.find({x:1}).hint("x_1")
// result is no documents returned because {x:1} is not indexed by the partial index
// Without $hint mongo should return {x:1}, thus the difference in result between COLSCAN and IXSCAN
DocumentDB will error out when $hint is applied on such cases.
db.col.find({x:1}).hint("x_1")
Error: error: {
"ok" : 0,
"operationTime" : Timestamp(1746473021, 1),
"code" : 2,
"errmsg" : "Cannot use Hint for this Query. Index is multi key index , partial index or sparse index and query is not optimized to use this index."
}
rs0:PRIMARY> db.runCommand({"planCacheSetFilter": "col", "query": { location: {$nearSphere: {$geometry: {type: "Point", coordinates: [1, 1]}}}}, "indexes": ["name_1"]})
{
"ok" : 0,
"operationTime" : Timestamp(1750815778, 1),
"code" : 303,
"errmsg" : "Unsupported query shape for index filter $nearSphere"
}
$nearkann $hint({“$natural”:1}) in Planner-Version 2.0 nicht verwendet werden.
// indexes present are index on x and geo index
rs0:PRIMARY> db.usarestaurants.getIndexes()
[
{
"v" : 4,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "test.usarestaurants"
},
{
"v" : 4,
"key" : {
"location" : "2dsphere"
},
"name" : "location_2dsphere",
"ns" : "test.usarestaurants",
"2dsphereIndexVersion" : 1
}
]
// Planner Version 2.0 will throw an error when $hint is applied with index "x_1"
rs0:PRIMARY> db.usarestaurants.find({ "location":{ "$nearSphere":{ "$geometry":{ "type":"Point", "coordinates":[ -122.3516, 47.6156 ] }, "$minDistance":1, "$maxDistance":2000 } } }, { "name":1 }).hint({"$natural": 1})
Error: error: {
"ok" : 0,
"operationTime" : Timestamp(1746475524, 1),
"code" : 291,
"errmsg" : "unable to find index for $geoNear query"
}
// Planner Version 1.0 and MongoDB will not throw an error
db.usarestaurants.find({ "location":{ "$nearSphere":{ "$geometry":{ "type":"Point", "coordinates":[ -122.3516, 47.6156 ] }, "$minDistance":1, "$maxDistance":2000 } } }, { "name":1 }).hint({"$natural": 1})
{ "_id" : ObjectId("681918e087dadfd99b7f0172"), "name" : "Noodle House" }
Während MongoDB vollständige Regex-Index-Scans unterstützt, unterstützt Planner Version 2.0 den Regex-Index-Scan nur für Präfixfelder.
// index on x
db.col.createIndex({x:1})
// index scan is used only for prefix regexes
rs0:PRIMARY> db.col.find({x: /^x/}).explain()
{
"queryPlanner" : {
"plannerVersion" : 2,
"namespace" : "test.col",
"winningPlan" : {
"stage" : "IXSCAN",
"indexName" : "x_1",
"direction" : "forward",
"indexCond" : {
"$and" : [
{
"x" : {
"$regex" : /^x/
}
}
]
},
"filter" : {
"x" : {
"$regex" : /^x/
}
}
}
},
"indexFilterSet" : false,
"indexFilterApplied" : false,
"ok" : 1,
"operationTime" : Timestamp(1746474527, 1)
}
// COLSCAN is used for non-prefix regexes
rs0:PRIMARY> db.col.find({x: /x$/}).explain()
{
"queryPlanner" : {
"plannerVersion" : 2,
"namespace" : "test.col",
"winningPlan" : {
"stage" : "COLLSCAN",
"filter" : {
"x" : {
"$regex" : /x$/
}
}
}
},
"indexFilterSet" : false,
"indexFilterApplied" : false,
"ok" : 1,
"operationTime" : Timestamp(1746474575, 1)
Es gibt einige inhärente Unterschiede bei der Verwendung von Plan-Cache-Filtern mit Planner-Version 2.0 im Vergleich zu MongoDB. Während die Planer-Version 2.0 die Angabe von „Projektion“ und „Sortierung“ mit Plan-Cache-Filtern nicht unterstützt, tut MongoDB dies. Der MongoDB-Indexfilter befindet sich jedoch nur im Arbeitsspeicher und geht nach dem Neustart verloren. In Planner Version 2.0 werden Indexfilter auch bei Neustarts und Patches beibehalten.
- Others
-
Das Format der DML-Auditprotokolle bei Verwendung der Planner-Version 2.0 unterscheidet sich geringfügig von dem der Planner-Version 1.0.
command - db.col.find({x:1})
************** Audit logs generated ******************
// v1 format for dml audit logs
{"atype":"authCheck","ts":1746473479983,"timestamp_utc":"2025-05-05 19:31:19.983","remote_ip":"127.0.0.1:47022","users":[{"user":"serviceadmin","db":"test"}],"param":{"command":"find","ns":"test.col","args":{"batchSize":101,"filter":{"x":1},"find":"col","limit":18446744073709551615,"lsid":{"id":{"$binary":"P6RCGz9ZS4iWBSSHWXW15A==","$type":"4"},"uid":{"$binary":"6Jo8PisnEi3dte03+pJFjdCyn/5cGQL8V2KqaoWsnk8=","$type":"0"}},"maxScan":18446744073709551615,"singleBatch":false,"skip":0,"startTransaction":false},"result":0}}
// v2 formal for dml audit logs
{"atype":"authCheck","ts":1746473583711,"timestamp_utc":"2025-05-05 19:33:03.711","remote_ip":"127.0.0.1:37754","users":[{"user":"serviceadmin","db":"test"}],"param":{"command":"find","ns":"test.col","args":{"find":"col","filter":{"x":1},"lsid":{"id":{"$binary":"nJ88TGCSSd+BeD2+ZtrhQg==","$type":"4"}},"$db":"test"},"result":0}}
-
Die Indexbedingung als Teil des Explain-Plans:
rs0:PRIMARY> db.col.createIndex({index1:1})
{
"createdCollectionAutomatically" : false,
"numIndexesBefore" : 1,
"numIndexesAfter" : 2,
"ok" : 1,
"operationTime" : Timestamp(1761149251, 1)
}
Planner Version 2.0 erklärt die Planausgabe mit Anzeige der Indexbedingung und des Filters:
rs0:PRIMARY> db.col.find({$and:[{price:{$eq:300}},{item:{$eq:"apples"}}]}).explain()
{
"queryPlanner" : {
"plannerVersion" : 2,
"namespace" : "test.col",
"winningPlan" : {
"stage" : "IXSCAN",
"indexName" : "price_1",
"direction" : "forward",
"indexCond" : {
"$and" : [
{
"price" : {
"$eq" : 300
}
}
]
},
"filter" : {
"$and" : [
{
"item" : {
"$eq" : "apples"
}
}
]
}
}
},
"indexFilterSet" : false,
"indexFilterApplied" : false,
"ok" : 1,
"operationTime" : Timestamp(1761149497, 1)
}
Planner Version 1.0 erklärt die Planausgabe:
rs0:PRIMARY> db.col.find({$and:[{price:{$eq:300}},{item:{$eq:"apples"}}]}).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "test.col",
"winningPlan" : {
"stage" : "IXSCAN",
"indexName" : "price_1",
"direction" : "forward"
}
},
"ok" : 1,
"operationTime" : Timestamp(1761149533, 1)
}
Planner Version 2.0 überbrückt Verhaltenslücken mit MongoDB
Es gibt einige Bereiche, in denen Planner Version 2.0 die Verhaltenslücken von MongoDB schließt:
Die Planner-Version 2.0 ermöglicht die numerische Indexsuche in abgeflachten Arrays für: $elemMatch
doc: {"x" : [ [ { "y" : 1 } ] ] }
// Planner Version 2 and mongo
> db.bar.find({"x.0": {$elemMatch: {y: 1}}})
{ "_id" : ObjectId("68192947945e5846634c455a"), "x" : [ [ { "y" : 1 } ] ] }
> db.bar.find({"x": {$elemMatch: {"0.y": 1}}})
{ "_id" : ObjectId("68192947945e5846634c455a"), "x" : [ [ { "y" : 1 } ] ] }
//Whereas Planner Version 1 wouldn't return any results.
> db.bar.find({"x.0": {$elemMatch: {y: 1}}})
> db.bar.find({"x": {$elemMatch: {"0.y": 1}}})
Während Planner Version 1.0 Zeichenketten in der Projektion ausschloss, entspricht das Verhalten von Planner Version 2.0 dem von MongoDB und behandelt sie als Literalwerte“
// Planner V2/ MongoDB
> db.col.find()
{ "_id" : ObjectId("681537738aa101903ed2fe05"), "x" : 1, "y" : 1 }
> db.col.find({},{x:"string"})
{ "_id" : ObjectId("681537738aa101903ed2fe05"), "x" : "string" }
// Planner V1 treats strings as exclude in projection
rs0:PRIMARY> db.col.find()
{ "_id" : ObjectId("68153744d42969f11d5cca72"), "x" : 1, "y" : 1 }
rs0:PRIMARY> db.col.find({},{x:"string"})
{ "_id" : ObjectId("68153744d42969f11d5cca72"), "y" : 1 }
Planner-Version 2.0 erlaubt wie MongoDB keine Projektion auf dieselben Felder „x“ und „x.a“:
// Planner version 2/MongoDB will error out
> db.col.find()
{ "_id" : ObjectId("68153da2012265816bc9ba23"), "x" : [ { "a" : 1 }, 3 ] }
db.col.find({},{"x.a":1,"x":1}) // error
// Planner Version 1 does not error out
db.col.find()
{ "_id" : ObjectId("68153da2012265816bc9ba23"), "x" : [ { "a" : 1 }, 3 ] }
db.col.find({},{"x.a":1,"x":1})
{ "_id" : ObjectId("68153d60143af947c720d099"), "x" : [ { "a" : 1 }, 3 ] }
Planner-Version 2.0 ermöglicht wie MongoDB die Projektion auf Unterdokumente:
// Planner Version2/MongoDB supports projections on subdocuments
db.col.find()
{ "_id" : ObjectId("681542d8f35ace71f0a50004"), "x" : [ { "y" : 100 } ] }
> db.col.find({},{"x":{"y":1}})
{ "_id" : ObjectId("681542b7a22d548e4ac9ddea"), "x" : [ { "y" : 100 } ] }
// Planner V1 throws error if projection is subdocument
db.col.find()
{ "_id" : ObjectId("681542d8f35ace71f0a50004"), "x" : [ { "y" : 100 } ] }
rs0:PRIMARY> db.col.find({},{"x":{"y":1}})
Error: error: {
"ok" : 0,
"operationTime" : Timestamp(1746223914, 1),
"code" : 2,
"errmsg" : "Unknown projection operator y"
}
In der Planner-Version 2.0 unterstützt die Projektion wie bei MongoDB keine Felder nach dem Operator: $
// Mongo and Planner Version 2 will error out
db.col.find()
{ "_id" : ObjectId("68155fa812f843439b593f3f"), "x" : [ { "a" : 100 } ] }
db.col.find({"x.a":100},{"x.$.a":1}) - // error
// v1 will not error out
db.col.find()
{ "_id" : ObjectId("68155fa812f843439b593f3f"), "x" : [ { "a" : 100 } ] }
db.col.find({"x.a":100},{"x.$.a":1})
{ "_id" : ObjectId("68155dee13b051d58239cd0a"), "x" : [ { "a" : 100 } ] }
Planner-Version 2.0 ermöglicht $hint wie MongoDB die Verwendung von:
// v1 will error out on $hint if there are no filters
db.col.find({}).hint("x_1")
Error: error: {
"ok" : 0,
"operationTime" : Timestamp(1746466616, 1),
"code" : 2,
"errmsg" : "Cannot use Hint for this Query. Index is multi key index , partial index or sparse index and query is not optimized to use this index."
}
// Mongo and Planner Version 2 will allow $hint usage
db.col.find({}).hint("x_1")
{ "_id" : ObjectId("6818f790d5ba9359d68169cf"), "x" : 1 }
