@@ -50,6 +50,9 @@ Covered queries are much faster than other queries, for two reasons:
50
50
indexes are typically stored in RAM *or* located sequentially on
51
51
disk, and indexes are smaller than the documents they catalog.
52
52
53
+ .. _index-sort:
54
+ .. _sorting-with-indexes:
55
+
53
56
Sort Using Indexes
54
57
~~~~~~~~~~~~~~~~~~
55
58
@@ -73,17 +76,55 @@ results. For example:
73
76
on ":ref:`Ascending and Descending Index Order
74
77
<index-ascending-and-descending>`."
75
78
76
- - MongoDB can use a compound index ``{ status: 1, username: 1 }`` to
77
- return a query on the ``status`` field sorted by the ``username``
78
- field.
79
+ - In general, MongoDB can use a compound index to return sorted
80
+ results *if*:
81
+
82
+ - the first sorted field is first field in the index.
83
+
84
+ - the last field in the index before the first sorted field is an
85
+ equality match in the query.
86
+
87
+ Consider the example presented below for an illustration of this
88
+ concept.
89
+
90
+ .. example::
91
+
92
+ Given the following index:
93
+
94
+ .. code-block:: javascript
95
+
96
+ { a: 1, b: 1, c: 1, d: 1 }
97
+
98
+ The following query and sort operations will be able to use the
99
+ index:
100
+
101
+ .. code-block:: javascript
102
+
103
+ db.collection.find().sort( { a:1 } )
104
+ db.collection.find().sort( { a:1, b:1 } )
105
+
106
+ db.collection.find( { a:4 } ).sort( { a:1, b:1 } )
107
+ db.collection.find( { b:5 } ).sort( { a:1, b:1 } )
108
+
109
+ db.collection.find( { a:{ $gt:4 } } ).sort( { a:1, b:1 } )
110
+ db.collection.find( { b:{ $gt:5 } } ).sort( { a:1, b:1 } )
111
+
112
+ db.collection.find( { a:5 } ).sort( { a:1, b:1 } )
113
+ db.collection.find( { a:5 } ).sort( { b:1, c:1 } )
114
+
115
+ db.collection.find( { a:5, c:4, b:3 } ).sort( { d:1 } )
79
116
80
- When using compound indexes to support sort operations, the sorted
81
- field must be the *last* field in the index.
117
+ db.collection.find( { a:5, b:3, d:{ $gt:4 } } ).sort( { c:1 } )
118
+ db.collection.find( { a:5, b:3, c:{ $lt:2 }, d:{ $gt:4 } } ).sort( { c:1 } )
82
119
83
- .. TODO: not true! In 2.2, you can use, say, the index above for a query on
84
- username, sort by status, too.
120
+ However, the following query operations would not be able to sort
121
+ data using the index:
85
122
86
- .. is this not true in other version? what changed?
123
+ .. code-block:: javascript
124
+
125
+ db.collection.find().sort( { b:1 } )
126
+ db.collection.find( { b:5 } ).sort( { b:1 } )
127
+ db.collection.find( { b:{ $gt:5 } } ).sort( { a:1, b:1 } )
87
128
88
129
Store Indexes in Memory
89
130
~~~~~~~~~~~~~~~~~~~~~~~
@@ -134,6 +175,8 @@ MongoDB can only use *one* index to support any given
134
175
operation. However, each clause of an :operator:`$or` query can use
135
176
its own index.
136
177
178
+ .. _index-selectivity:
179
+
137
180
Selectivity
138
181
~~~~~~~~~~~
139
182
@@ -225,9 +268,55 @@ the insertion penalty; however:
225
268
on some queries if it means consolidating the total number of
226
269
indexes.
227
270
228
- .. TODO: do you cover what indexes overlap?
271
+ - If your indexes and queries are not very selective, the speed
272
+ improvements for query operations may not offset the costs of
273
+ maintaining an index. See the section on :ref:`index selectivity
274
+ <index-selectivity>` for more information.
275
+
276
+ - In some cases a single compound on two or more fields index may
277
+ support all of the queries that index on a single field index, or a
278
+ smaller compound index. In general, MongoDB can use compound index
279
+ to support the same queries as any of its prefixes. Consider the
280
+ following example:
281
+
282
+ .. example::
283
+
284
+ Given the following index on a collection:
285
+
286
+ .. code-block:: javascript
287
+
288
+ { x: 1, y: 1, z: 1 }
289
+
290
+ Can support a number of queries as well as most of the queries
291
+ that the following indexes support:
292
+
293
+ .. code-block:: javascript
294
+
295
+ { x: 1 }
296
+ { x: 1, y: 1 }
297
+
298
+ There are some situations where the prefix indexes may offer
299
+ better query performance as is the case if ``z`` is a large
300
+ array. Also, consider the following index on the same collection:
301
+
302
+ .. code-block:: javascript
303
+
304
+ { x: 1, z: 1 }
305
+
306
+ The ``{ x: 1, y: 1, z: 1 }`` index can support many of the same
307
+ queries as the above index; however, ``{ x: 1, z: 1 }`` has
308
+ additional use: Given the following query:
309
+
310
+ .. code-block:: javascript
311
+
312
+ db.collection.find( { x: 5 } ).sort( { z: 1} )
313
+
314
+ The ``{ x: 1, z: 1 }`` will support both the query and the sort
315
+ operation, while the ``{ x: 1, y: 1, z: 1 }`` index can only
316
+ support the query.
229
317
230
- .. no. I'm not sure the case to which you're referring.
318
+ See the :ref:`sorting-with-indexes` section for more
319
+ information.
231
320
232
321
Index Size
233
322
~~~~~~~~~~
0 commit comments