Skip to content

Commit 2e6a1b8

Browse files
author
Sam Kleinman
committed
DOCS-330 adding examples based on feedback from astaple
1 parent 2eac86c commit 2e6a1b8

File tree

1 file changed

+99
-10
lines changed

1 file changed

+99
-10
lines changed

draft/applications/indexes.txt

Lines changed: 99 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -50,6 +50,9 @@ Covered queries are much faster than other queries, for two reasons:
5050
indexes are typically stored in RAM *or* located sequentially on
5151
disk, and indexes are smaller than the documents they catalog.
5252

53+
.. _index-sort:
54+
.. _sorting-with-indexes:
55+
5356
Sort Using Indexes
5457
~~~~~~~~~~~~~~~~~~
5558

@@ -73,17 +76,55 @@ results. For example:
7376
on ":ref:`Ascending and Descending Index Order
7477
<index-ascending-and-descending>`."
7578

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

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

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:
85122

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

88129
Store Indexes in Memory
89130
~~~~~~~~~~~~~~~~~~~~~~~
@@ -134,6 +175,8 @@ MongoDB can only use *one* index to support any given
134175
operation. However, each clause of an :operator:`$or` query can use
135176
its own index.
136177

178+
.. _index-selectivity:
179+
137180
Selectivity
138181
~~~~~~~~~~~
139182

@@ -225,9 +268,55 @@ the insertion penalty; however:
225268
on some queries if it means consolidating the total number of
226269
indexes.
227270

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.
229317

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.
231320

232321
Index Size
233322
~~~~~~~~~~

0 commit comments

Comments
 (0)