MongoDB misuses GeoSpatialIndexes within CompoundIndexes when sorting - mongodb

Question

I go to the Mongo command line (version 4.4.1) and do
db.places.dropIndexes()
db.places.createIndex( { location : "2dsphere" , category1 : 1 } )
db.places.createIndex( { location : "2dsphere" , category2 : 1 } )
db.places.find({ location: { $near: { $geometry: { type: "Point", coordinates: [ 0, 0 ] } } } }).sort({ category2 : 1 }).explain()
The result shows that the index (location, category2) is not used, event though there is a perfect match for the query (find by location and sort by category2).
The winning plan shows the category1 index is used:
"indexName" : "location_2dsphere_category1_1",
db.places.find({ location: { $near: { $geometry: { type: "Point", coordinates: [ 0, 0 ] } } } }).sort({ category2 : 1 }).explain()
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "dev.places",
"indexFilterSet" : false,
"parsedQuery" : {
"location" : {
"$near" : {
"$geometry" : {
"type" : "Point",
"coordinates" : [
0,
0
]
}
}
}
},
"queryHash" : "8766F2A3",
"planCacheKey" : "9B5661A5",
"winningPlan" : {
"stage" : "SORT",
"sortPattern" : {
"category2" : 1
},
"memLimit" : 104857600,
"type" : "simple",
"inputStage" : {
"stage" : "GEO_NEAR_2DSPHERE",
"keyPattern" : {
"location" : "2dsphere",
"category1" : 1
},
"indexName" : "location_2dsphere_category1_1",
"indexVersion" : 2,
"inputStage" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"location" : "2dsphere",
"category1" : 1
},
"indexName" : "location_2dsphere_category1_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"location" : [ ],
"category1" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"location" : [
"[-9223372036854775807, -6917529027641081857]",
"[-6917529027641081855, -4611686018427387905]",
"[1, 2305843009213693951]",
"[2305843009213693953, 4611686018427387903]",
"[4611686018427387905, 6917529027641081855]",
"[6917529027641081857, 9223372036854775807]"
],
"category1" : [
"[MinKey, MaxKey]"
]
}
}
}
}
},
"rejectedPlans" : [
{
"stage" : "SORT",
"sortPattern" : {
"category2" : 1
},
"memLimit" : 104857600,
"type" : "simple",
"inputStage" : {
"stage" : "GEO_NEAR_2DSPHERE",
"keyPattern" : {
"location" : "2dsphere",
"category2" : 1
},
"indexName" : "location_2dsphere_category2_1",
"indexVersion" : 2,
"inputStage" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"location" : "2dsphere",
"category2" : 1
},
"indexName" : "location_2dsphere_category2_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"location" : [ ],
"category2" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"location" : [
"[-9223372036854775807, -6917529027641081857]",
"[-6917529027641081855, -4611686018427387905]",
"[1, 2305843009213693951]",
"[2305843009213693953, 4611686018427387903]",
"[4611686018427387905, 6917529027641081855]",
"[6917529027641081857, 9223372036854775807]"
],
"category2" : [
"[MinKey, MaxKey]"
]
}
}
}
}
}
]
},
"serverInfo" : {
"host" : "XXXX",
"port" : 27017,
"version" : "4.4.1",
"gitVersion" : "ad91a93a5a31e175f5cbf8c69561e788bbc55ce1"
},
"ok" : 1
}
"winningPlan" : {
"stage" : "SORT",
"sortPattern" : {
"category2" : 1
},
"memLimit" : 104857600,
"type" : "simple",
"inputStage" : {
"stage" : "GEO_NEAR_2DSPHERE",
"keyPattern" : {
"location" : "2dsphere",
"category1" : 1
},
"indexName" : "location_2dsphere_category1_1",

Answer 1

See https://www.alexbevi.com/blog/2020/05/16/optimizing-mongodb-compound-indexes-the-equality-sort-range-esr-rule/.
$near is a range query and the index must reference the field being sorted on before fields that have range conditions on them to satisfy both range and sort requirements.
Neither of your indexes can be used to sort your query. MongoDB picks the first one since the usable part of them is just the geo index.
Since you haven't specified a distance with $near you are probably getting all documents that have the location field set via the index scan.