Planificador de consultas v2 - Amazon DocumentDB

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Planificador de consultas v2

El nuevo planificador de consultas para Amazon DocumentDB (versión 2.0 del planificador) incluye características avanzadas de optimización de consultas y un rendimiento mejorado. La versión 2.0 del planificador para Amazon DocumentDB 5.0 mejora el rendimiento hasta 10 veces con respecto a la versión anterior cuando se utilizan los operadores find y update con índices. Las mejoras en el rendimiento se deben principalmente al uso de planes de indexación más óptimos y a que se habilita el escaneo de índices para operadores como los operadores de negación ($neq, $nin) y anidados $elementMatch. Las consultas de la versión 2.0 del planificador se ejecutan más rápido gracias a mejores técnicas de estimación de costos, algoritmos optimizados y una estabilidad mejorada. La versión 2.0 de Planner también es compatible con el filtro APIs de caché del plan, lo que mejora la estabilidad del planificador. Con esta característica, Amazon DocumentDB 5.0 ahora ofrece la posibilidad de seleccionar entre las distintas versiones del planificador de consultas.

Requisitos previos

Para usar la versión 2.0 del planificador, se deben cumplir los siguientes requisitos previos:

  • La versión 2.0 del planificador está disponible en todas las regiones en las que está disponible la versión 5.0 del motor.

  • Para optar por utilizar la versión 2.0 como planificador de consultas predeterminado, el clúster debe tener el parche del motor 3.0.15902 o posterior de la versión 5.0 de Amazon DocumentDB. Para obtener información sobre los pasos para actualizar el parche a la última versión del motor, consulte Actualización de un parche a la versión del motor de un clúster.

  • Para configurar la versión 2.0 del planificador como el planificador de consultas predeterminado, necesita permisos de IAM para actualizar los grupos de parámetros del clúster.

Selección de la versión 2.0 del planificador como planificador de consultas predeterminado

Siga los siguientes pasos para seleccionar 2.0 como el planificador de consultas predeterminado desde la consola o la CLI:

  • Siga los pasos en Modificación de parámetros de clúster de Amazon DocumentDB para modificar el grupo de parámetros del clúster.

  • Para el parámetro denominado «plannerVersion», cambie el valor a 2.0 para indicar la versión 2.0 del planificador.

  • Seleccione Aplicar inmediatamente (si selecciona Aplicar al reiniciar, la selección no será válida hasta el siguiente reinicio del clúster).

Prácticas recomendadas

Para obtener los resultados esperados, utilice las siguientes prácticas recomendadas cuando aplique la versión 2.0 del planificador:

  • En un clúster global, seleccione el mismo valor de la plannerVersion (1.0 o 2.0) en los grupos de parámetros del clúster para ambas regiones. Tenga en cuenta que seleccionar diferentes versiones del planificador en las regiones principales y secundarias puede provocar que el comportamiento y el rendimiento de las consultas no sea constante.

  • La actualización a la versión 2.0 del planificador durante un período de mantenimiento programado o durante períodos de tráfico reducido será lo menos molesto, ya que puede haber un aumento en las tasas de error si se cambia la versión del planificador cuando las cargas de trabajo se están ejecutando activamente.

  • La versión 2.0 del planificador funciona de manera óptima con el shell de MongoDB, versión 5.0.

Limitaciones

Las siguientes limitaciones se aplican a la versión 2.0 del planificador:

  • La versión 2.0 del planificador no es compatible con los clústeres elásticos, que recurrirán a la versión 1.0 del planificador.

  • La versión 2.0 del planificador no admite la agregación ni los comandos distintos, por lo que se recurrirá a la versión 1.0 del planificador.

  • El filtro de caché del plan de la versión 2.0 del planificador no admite consultas que contengan expresiones regulares, búsquedas de texto, geoespaciales, jsonschema ni $expr en filtros.

Mejoras en operadores Find y Update

La versión 2.0 del planificador optimiza las operaciones fundamentales, incluidos los comandos find, update, delete y find-and-modify. Las siguientes secciones con pestañas muestran las capacidades mejoradas de los índices, así como las mejoras en el rendimiento de las consultas con la versión 2.0 del planificador:

Enhanced index support
  • La versión 2.0 del planificador añade compatibilidad con índices para los operadores de negación, incluidos $nin, $ne, $not {eq}, $not {in}, $type y $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 }}}}})
  • La versión 2.0 del planificador utiliza índices dispersos o parciales incluso cuando $exists no está presente en la expresión de consulta.

    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" })
  • La versión 2.0 del planificador utilizará índices parciales incluso cuando la condición de consulta no coincida exactamente con la expresión del filtro de índice parcial.

    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}})
  • La versión 2.0 del planificador utiliza un escaneo parcial del índice con consultas de $elemMatch.

    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}}})
  • La versión 2.0 del planificador incluye soporte con escaneo de índices para $regex, sin necesidad de incluir $hint en el código de la aplicación. $regex solo admite búsquedas de indexación por prefijo.

    Sample Document: { "x": [1, 2, 3], "y": "apple" } db.foo.createIndex({ "x": 1, "y": 1 }) db.foo.find({"y":{ $regex: "^a" }})
  • La versión 2.0 del planificador mejora el rendimiento de las consultas que utilizan índices de claves múltiples, con condiciones de igualdad en los campos de claves múltiples.

    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)
  • La versión 2.0 del planificador mejora el rendimiento de las consultas que utilizan filtros múltiples, especialmente en colecciones con documentos de más de 8 KB.

    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}}]})
  • La versión 2.0 del planificador mejora el rendimiento de las consultas cuando se utiliza el operador $in con un índice compuesto al eliminar la etapa de clasificación.

    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})

    También mejora el rendimiento de las consultas que utilizan índices de varias claves con $in elementos.

    Sample Document: {"x": [1, 2, 3]} db.foo.createIndex({"x": 1}) db.foo.find("x":{$in:[>100 elements]})
Query performance improvements
  • La versión 2.0 del planificador mejora el rendimiento de las consultas que utilizan filtros múltiples, especialmente en colecciones con documentos de más de 8 KB.

    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}}]})
  • La versión 2.0 del planificador mejora el rendimiento de las consultas cuando se utiliza el operador $in con un índice compuesto al eliminar la etapa de clasificación.

    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})

    También mejora el rendimiento de las consultas que utilizan índices de claves múltiples con elementos $in.

    Sample Document: {"x": [1, 2, 3]} db.foo.createIndex({"x": 1}) db.foo.find("x":{$in:[>100 elements]})

API del filtro de caché del plan

nota

El índice de texto no es compatible con el filtro de caché del plan.

  • La versión 2.0 del planificador añade compatibilidad con la característica de filtro de índices que permite especificar una lista de índices que puede utilizar una forma de consulta específica. Se puede acceder a esta característica a través de la API y se puede controlar desde el servidor. Si experimenta una regresión de consultas, esta característica le ofrece una opción más rápida y flexible para mitigar el problema sin tener que modificar el código de la aplicación.

    db.runCommand({ planCacheSetFilter: <collection>, query: <query>, sort: <sort>, // optional, indexes: [ <index1>, <index2>, ...], comment: <any> // optional})

    Para mostrar todos los filtros de la colección, use el siguiente comando:

    db.runCommand( { planCacheListFilters: <collection> } )

    Este comando muestra todos los filtros de índice de la colección. Ejemplo de código de salida:

    { "filters" : [ { "query" : {a: "@", b: "@"}, "sort" : {a: 1}, "indexes" : [ <index1>, ... ] }, ... ], "ok": 1 }
  • Puede utilizar dos campos nuevos del resultado del comando explain para analizar el filtrado de índices de la versión 2.0 del planificador: indexFilterSet y indexFilterApplied. indexFilterSet se establece en «verdadero» si hay un filtro de índice establecido en la colección que coincide con la forma de la consulta. indexFilterApplied se establece en «verdadero» si, y solo si, la consulta aplicó un filtro de índice y eligió un plan mediante el uso de un índice de la lista de filtros.

    Puede borrar el filtro de índice con el siguiente comando:

    db.runCommand( { planCacheClearFilters: <collection>> query: <query pattern>, // optional sort: <sort specification>, // optional comment: <any>. //optional } )

    Para borrar todos los filtros de la colección «foo», use el siguiente comando:

    db.runCommand({planCacheClearFilters: "foo"})

    Para borrar una forma de consulta específica con cualquier tipo, puede copiar y pegar la forma de consulta desde el resultado de planCacheListFilters:

    db.runCommand({planCacheClearFilters: "foo", query: {a: @}})

    Para borrar una forma de consulta específica con un campo especificado en cualquier tipo, puede copiar y pegar la forma de consulta desde el resultado de planCacheListFilters:

    db.runCommand({planCacheClearFilters: "foo", query: {a: @},sort: {a: 1}})

Posibles diferencias de comportamiento entre el planificador, versión 1.0, 2.0 y MongoDB

En algunos casos extremos, es posible que la versión 2.0 del planificador produzca resultados que varíen ligeramente de los resultados de MongoDB. En esta sección se describen algunos ejemplos de estas posibilidades.

$(update) and $(projection)
  • En algunos casos, los operadores $(update) y $(projection) de MongoDB pueden comportarse de forma diferente a la versión 1.0 del planificador de Amazon DocumentDB. A continuación se muestran algunos ejemplos:

    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 } }
    • Planificador, versión 1.0: actualiza el campo 2022.

    • MongoDB: actualiza el campo 2022.

    • Planificador, versión 2.0: actualiza el campo 2021.

  • db.col.insert({x:[1,2,3]}) db.col.update({$and:[{x:1},{x:3}]},{$set:{"x.$":500}})
    • Planificador, versión 1.0: actualiza aleatoriamente el primer elemento coincidente.

    • MongoDB: actualiza aleatoriamente el primer elemento coincidente.

    • Planificador, versión 2.0: no realiza actualizaciones.

  • db.col.insert({x:[1,2,3]}) db.col.find()
    • Planificador, versión 1.0: selecciona aleatoriamente el elemento coincidente.

    • MongoDB: selecciona aleatoriamente el elemento coincidente.

    • Planificador, versión 2.0: no realiza ninguna selección.

  • db.col.insert({x:100}) db.col.update({x:100},{x:100})
    • Planificador, versión 1.0: cambios en el recuento nModified.

    • MongoDB: cambios en el recuento nModified.

    • Planificador, versión 2.0: el recuento nModified no cambia cuando se actualiza con el mismo valor.

  • Cuando se usa el operador $(update) con $setOnInsert, la versión 1.0 del planificador y MongoDB arrojan un error, pero la versión 2.0 del planificador no.

  • Si se cambia el nombre de un campo que no existe a $field, se produce un error en la versión 2.0 del planificador, mientras que no se producen actualizaciones en la versión 1.0 del planificador ni en MongoDB.

Index behavior
  • La versión 2.0 del planificador arroja un error cuando se aplica $hint con un índice inadecuado, mientras que la versión 1.0 del planificador y MongoDB no lo hacen.

    // 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" }
  • $near no puede utilizar $hint({“$natural”:1}) en la versión 2.0 del planificador.

    // 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" }
  • Si bien MongoDB admite escaneos completos de índices de expresiones regulares, la versión 2.0 del planificador admite el escaneo de índices de expresiones regulares solo en los campos con prefijo.

    // 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)
  • Existen algunas diferencias inherentes al uso de filtros de caché del plan con la versión 2.0 del planificador en comparación con MongoDB. Si bien la versión 2.0 del planificador no admite especificar la «proyección» y la «intercalación» con los filtros de caché del plan, MongoDB sí lo hace. Sin embargo, el filtro de índice de MongoDB solo está en memoria y se pierde tras el reinicio. La versión 2.0 del planificador conserva los filtros de índice mediante reinicios y parches.

Others
  • El formato de los registros de auditoría de DML cuando se utiliza la versión 2.0 del planificador varía ligeramente de la versión 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}}
  • La condición del índice como parte del plan explicativo:

    rs0:PRIMARY> db.col.createIndex({index1:1}) { "createdCollectionAutomatically" : false, "numIndexesBefore" : 1, "numIndexesAfter" : 2, "ok" : 1, "operationTime" : Timestamp(1761149251, 1) }

    La versión 2.0 del planificador explica el resultado del plan, mostrando la condición del índice y el filtro:

    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) }

    Resultado del plan explicativo de la versión 1.0 del planificador:

    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) }

La versión 2.0 del planificador cierra la brecha de comportamiento con MongoDB

Hay algunas áreas en las que la versión 2.0 del planificador cierra las brechas de comportamiento con MongoDB:

  • La versión 2.0 del planificador permite la búsqueda de índices numéricos en matrices aplanadas para $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}}})
  • Si bien la versión 1.0 del planificador excluía las cadenas en la proyección, el comportamiento de la versión 2.0 del planificador se alinea con MongoDB y las trata como valores literales.

    // 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 }
  • La versión 2.0 del planificador, como MongoDB, no permite la proyección en los mismos campos «x» y «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 ] }
  • La versión 2.0 del planificador, como MongoDB, permite la proyección en subdocumentos:

    // 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" }
  • Con la versión 2.0 del planificador, como MongoDB, la proyección no admite campos después del operador $:

    // 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 } ] }
  • La versión 2.0 del planificador, como MongoDB, permite el uso de $hint:

    // 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 }