Tri avec sort() et plusieurs clés

The sort() method appended to a find() cursor tells MongoDB to return documents in a specific order. Pass an object where each key is a field name and each value is 1 (ascending) or -1 (descending). Sorting happens on the server before documents are sent to the client, so you receive results in order regardless of how many documents match.

MongoDB sorts by the first key first, then uses subsequent keys to break ties. Pass multiple fields in the sort object. The order of keys matters: the first key is the primary sort, the second is the tiebreaker. A common example is sorting products by category ascending, then by price descending within each category.

When the sort fields match an index, MongoDB can satisfy the sort without loading and sorting all documents in memory. It walks the index in the requested direction instead. This is called an index sort and it is dramatically faster than an in-memory sort, especially on large collections. Always create an index that covers your most common sort operations.

If a sort cannot use an index, MongoDB must load all matching documents into memory to sort them. This in-memory sort has a hard limit of 32 MB. If the matching documents exceed 32 MB, the sort fails with Executor error: OperationFailed: Sort exceeded memory limit. The fix is to add an index that supports the sort, or use allowDiskUse: true in aggregation pipelines.

For a compound index to serve a compound sort, the directions must align—either exactly match or completely reverse. An index on { a: 1, b: 1 } supports sorts on { a: 1, b: 1 } (forward scan) and { a: -1, b: -1 } (backward scan) but cannot support { a: 1, b: -1 } or { a: -1, b: 1 }. Mixed-direction sorts require an index that matches the mixed directions exactly.

The $natural sort key returns documents in their natural on-disk insertion order. { $natural: 1 } returns documents in insertion order; { $natural: -1 } returns them in reverse. This bypasses all indexes and is rarely used in production—it is mainly useful for capped collections, which maintain strict insertion order for log-like workloads.

Sorting is almost always combined with limit() to fetch only the top N results, and sometimes with skip() for paginated results. The operation order is: filter → sort → skip → limit. MongoDB applies them in this sequence regardless of the order you chain them in your driver code. Sorting before limiting is what lets you get the 'top 10' results correctly.

Mongoose's query builder exposes .sort() with the same syntax as the native driver, plus a convenience string form. Pass a string of field names prefixed with + (ascending) or - (descending), separated by spaces. Both forms are equivalent and the driver compiles them to the same MongoDB sort document.

In MongoDB sort results, documents where the sort field is missing or null sort as if the field value is null. In ascending order, null and missing values appear first (before any other value). In descending order they appear last. Be aware of this behaviour when some documents are missing the sort field—it can cause unexpected ordering in mixed-schema collections.

MongoDB's sort is not guaranteed stable when two documents have the same value for the sort key—their relative order is undefined and may change between queries. To get a deterministic, stable ordering, always include _id as a final tiebreaker. Since _id is unique, it guarantees a consistent order even when primary sort keys are equal.

Run explain('executionStats') and look for the SORT stage in the execution plan. If you see an IXSCAN feeding directly into a cursor without a SORT stage, the sort is served by the index (ideal). If there is a SORT stage, the sort is in-memory and an index might help. Also check memUsage inside the SORT stage to understand how much memory the sort consumed.

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

In this lesson you learned: sort() accepts a document of field-direction pairs where 1 is ascending and -1 is descending, compound sorts use later fields as tiebreakers, and matching an index avoids the 32 MB in-memory sort limit. Next up we explore skip and limit offset pagination and its performance trade-offs at scale.