การทำงานของดัชนี B-Tree ใน MongoDB

Without an index, MongoDB must scan every document in a collection to satisfy a query—this is called a collection scan (COLLSCAN). On a collection with millions of documents, a COLLSCAN can take seconds or even minutes. An index is a separate, ordered data structure that lets MongoDB jump directly to the matching documents in microseconds.

MongoDB uses a B-tree (balanced tree) to store index entries. A B-tree is organised as a hierarchy of nodes: a root node at the top, internal nodes in the middle, and leaf nodes at the bottom. Every node holds multiple key-value pairs and pointers to child nodes. The tree stays balanced—all leaf nodes are at the same depth—so lookups always take the same number of steps regardless of which value you search for.

When you create an index on a field like age, MongoDB builds a B-tree where each leaf node entry contains the indexed field value paired with a pointer (the RecordId) to the actual document on disk. The entries are sorted in ascending or descending order based on how you define the index. Because the tree is sorted, MongoDB can satisfy equality lookups, range queries, and sort operations all from the same structure.

Every query passes through MongoDB's query planner, which evaluates available indexes and chooses the most efficient execution plan. When the planner finds a suitable index, it uses an IXSCAN (index scan) stage instead of a COLLSCAN. An IXSCAN traverses the B-tree from root to the matching leaf nodes, then fetches only the relevant documents from disk using their RecordId pointers.

A B-tree index supports three types of access patterns: equality lookups (find the exact key), range scans (traverse contiguous leaf nodes between two bounds), and sort operations (the tree is already ordered, so no in-memory sort is needed). This triple capability makes a well-placed index dramatically more useful than it might first appear.

When you create an index with 1 the entries are stored in ascending order; -1 stores them in descending order. For a single-field index, direction doesn't matter much because MongoDB can traverse the B-tree in either direction. Direction becomes critical in compound indexes where the combination of directions must match the sort order your queries use.

MongoDB tries to keep the working set of indexes in RAM (the WiredTiger cache). When an index fits entirely in memory, lookups are essentially free I/O operations. When an index is too large for RAM, MongoDB must page index nodes in from disk, which causes latency spikes. This is why you should keep indexes lean—only index the fields you actually query, and use projection to avoid returning unused data.

A covered query is one where all the fields in the filter and projection are present in the index. MongoDB can answer such a query using only the index B-tree—it never has to fetch the actual document from disk. Covered queries are extremely fast and are worth designing for on your hottest read paths.

Every MongoDB collection automatically has a unique B-tree index on _id. This default index is why lookups by _id are always fast, even on enormous collections. You cannot drop the _id index. All other indexes are optional and must be created explicitly by the developer or DBA.

Indexes speed up reads but slow down writes. Every insert, update, or delete must update not only the document on disk but also every B-tree that indexes a field on that document. A collection with 10 indexes incurs 10 extra B-tree writes per insert. This trade-off means you should only create indexes that serve real query patterns—zombie indexes that nobody uses still pay the write tax.

When you index a field that contains an array, MongoDB creates a multikey index—it inserts one B-tree entry per array element. This allows queries like { tags: 'mongodb' } to use the index even though tags is an array. MongoDB detects array fields automatically and sets the multikey flag; you don't need to do anything special when creating the index.

Test your understanding of MongoDB B-Tree indexes from this lesson.

In this lesson you learned: MongoDB uses B-tree structures where sorted leaf entries point to document RecordIds, the query planner chooses IXSCAN over COLLSCAN when a suitable index exists, and indexes accelerate reads but add write overhead. Next up we explore creating single-field and compound indexes.