Abfrageplaner

Planner Version 2.0 bietet Indexunterstützung für Negationsoperatoren wie $nin$ne, $not {eq}$not {in}, und sowie 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 dünnbesetzte Indizes oder partielle Indizes, 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 partiellen 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 bietet Unterstützung für Indexscans$regex, ohne dass Sie $hint in Ihrem Anwendungscode angeben müssen. $regexunterstützt nur Indexsuchen nach Präfixen.

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 verwenden, 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, da 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]})

Planner Version 2.0 verbessert die Leistung von Abfragen, die mehrere Filter verwenden, 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, da 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]})

In einigen Fällen verhalten sich $(update) $(projection) Operatoren in MongoDB möglicherweise anders als die 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 } }

db.col.insert({x:[1,2,3]})
db.col.update({$and:[{x:1},{x:3}]},{$set:{"x.$":500}})

db.col.insert({x:[1,2,3]})
db.col.find()

db.col.insert({x:100})
db.col.update({x:100},{x:100})

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 $field löst in Planner Version 2.0 einen Fehler aus, wohingegen in Planner Version 1.0 und MongoDB keine Updates erzeugt werden.

Planner Version 2.0 gibt einen Fehler aus, wenn sie mit einem ungeeigneten Index angewendet $hint wird, Planner Version 1.0 und MongoDB dagegen nicht.

// 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-Indexscans unterstützt, unterstützt Planner Version 2.0 den Regex-Indexscan 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 Planner-Version 2.0 die Angabe von „Projektion“ und „Kollation“ 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. Planner Version 2.0 behält Indexfilter bei Neustarts und Patches bei.

Das Format der DML-Prüfprotokolle bei Verwendung von Planner Version 2.0 unterscheidet sich geringfügig von dem Format 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)
}