-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 5.0.0, 6.0.0
-
Component/s: None
-
Query Optimization
-
Fully Compatible
-
v6.3, v6.0, v5.0
-
QO 2023-03-20, QO 2023-04-03
-
(copied to CRM)
A query that uses $in on _id does not plan against a clustered index if one exists. If no suitable secondary index exists, we fall back to a collection scan.
This affects queries directly on time-series buckets collections.
test> db.createCollection('clustered', {clusteredIndex: {key: {_id: 1}, unique: true}}) test> db.clustered.find({_id: {$in: [0,1,2,3]}}).explain() { explainVersion: '1', queryPlanner: { namespace: 'test.clustered', indexFilterSet: false, parsedQuery: { _id: { '$in': [ 0, 1, 2, 3 ] } }, queryHash: '0D7870DC', planCacheKey: '0D7870DC', maxIndexedOrSolutionsReached: false, maxIndexedAndSolutionsReached: false, maxScansToExplodeReached: false, winningPlan: { stage: 'COLLSCAN', filter: { _id: { '$in': [ 0, 1, 2, 3 ] } }, direction: 'forward' }, rejectedPlans: [] },
- causes
-
SERVER-76102 handleRIDRangeScan() sets hasCompatibleCollation wrong in recursive cases
- Closed
- is related to
-
SERVER-75063 Support more complex scan bounds for clustered index
- Open