Index attributes (unique index, sparse index, partial index)

The MongoDB indexing mechanism optimizes query performance through different types and properties. Unique indexes ensure field values are not duplicated, similar to the UNIQUE constraint in relational databases. Compound unique indexes require the combination of values to be unique. Sparse indexes only include documents with the indexed field, skipping null or non-existent fields, making them suitable for optional field scenarios. Partial indexes only create indexes for documents that meet specific conditions, reducing storage and maintenance costs. In practice, multiple index properties can be combined, such as using a unique and sparse index together to address duplicate null values. The article also provides an indexing design case for an e-commerce platform's product collection, along with index maintenance strategies, including methods for viewing statistics and rebuilding indexes, to help developers efficiently manage database indexes.

Hash index and TTL index

A hash index is a special type of single-field index in MongoDB that uses a hash function to compute field values and stores the results. It only supports exact match queries and not range queries, making it suitable for scenarios with frequent equality queries and uneven data distribution. A TTL (Time-To-Live) index is another special index that allows automatic deletion of expired documents based on a date-type field. It is ideal for managing temporary data such as session information and logs. The two serve different purposes: hash indexes optimize query performance, while TTL indexes automate data cleanup. Hash indexes do not support compound indexes, whereas TTL indexes require a date-type field. In practical applications, they can be combined—for example, in a message queue system, a hash index can accelerate lookups while a TTL index automatically cleans up data. Performance-wise, hash indexes incur write overhead, and TTL index deletion operations may increase system load. Best practices include selecting the appropriate index type based on business needs and setting reasonable expiration times. The article also covers internal mechanisms, limitations, and handling of special scenarios.

Geospatial indexes (2d, 2dsphere)

MongoDB provides two types of geospatial indexes, 2d and 2dsphere, for handling geospatial data queries in different scenarios. The 2d index is suitable for flat coordinate systems, processing simple two-dimensional point data, and supports query operations like `near` and `geoWithin`. The 2dsphere index, on the other hand, is based on a spherical coordinate system, supporting complex geospatial data types such as points, lines, and polygons, with data stored in GeoJSON format. Both indexes can significantly improve query performance. In practice, the appropriate index can be chosen based on the data type: 2d is suitable for small-scale planar data, while 2dsphere is ideal for Earth-surface data. The article also introduces examples of geospatial queries, including nearby location searches and geofencing applications, as well as index optimization techniques such as creating compound indexes and performance considerations. Finally, advanced usage is mentioned, such as combining full-text search and dynamic query construction.

Full-text indexing and text search

MongoDB full-text indexing is a special type of index that supports efficient text search by understanding linguistic features such as stemming and stop-word filtering, making it suitable for scenarios like content management and product catalogs. Full-text indexes are created using the `createIndex` method, where fields and weights can be specified. Searches are performed using the `$text` operator, which supports phrase searches, exclusion terms, and multilingual advanced features. Search results can be sorted by relevance score, and text search can also be used within aggregation pipelines. Full-text indexes have collection and size limitations, and optimization recommendations include setting appropriate weights and combining queries. Compared to traditional databases, MongoDB's full-text search is more flexible but less powerful than dedicated search engines. Performance monitoring can be done using the `explain` method, and precise matching can be achieved by combining it with regular expressions.

Multi-key indexing (array field indexing)

A multi-key index is a special type of index in MongoDB designed for array fields. It creates index entries for each element in the array rather than for the entire array. The syntax is the same as for a regular index, and MongoDB automatically detects array fields to create multi-key indexes, enabling efficient queries on array elements, including equality matches, range queries, and the `$elemMatch` operator. However, there are limitations, such as compound indexes only being able to include one array field and not supporting covered queries. Performance optimization recommendations include creating compound indexes with non-array fields and using `$elemMatch`. Monitoring index usage can be done via the `explain` method. Multi-key indexes are suitable for various array query scenarios, including array length, specific position elements, and nested arrays, and can also be combined with text search. However, large arrays may increase index size and fragmentation issues. In the aggregation pipeline, the `$unwind` and `$match` stages can be optimized. Rebuilding or dropping and recreating indexes can resolve fragmentation issues and free up storage space.

Single-field index and composite index

MongoDB index types include single-field indexes and compound indexes. Single-field indexes are created for a single field and are suitable for simple queries, while compound indexes are based on multiple fields and follow the leftmost prefix principle, making them ideal for complex queries. When selecting indexes, factors such as query frequency, field selectivity, and sorting requirements should be considered. Optimization techniques include covered queries, index intersection, and partial indexes. Common issues include index bloat, write performance degradation, and insufficient memory, which can be addressed by monitoring index usage, regularly rebuilding indexes, and removing unused indexes. Practical case studies demonstrate index optimization strategies for e-commerce platforms and logging systems, where well-designed indexes significantly improve query performance.

The role and principle of indexes

An index is a data structure in a database that speeds up queries. In MongoDB, indexes can improve query performance, ensure data uniqueness, and optimize sorting operations. When dealing with large amounts of data, queries without indexes require full collection scans, resulting in low efficiency. Indexes use a B-tree structure to maintain data order and support efficient operations. The query optimizer evaluates and selects the best index. Index types include single-field, compound, multikey, geospatial, and full-text indexes. Indexes are stored on disk separately from data and may occupy significant space. Choosing indexes requires considering query patterns. Too many indexes can increase write overhead. Indexes have limitations, such as occupying space, reducing write performance, and being ineffective for certain queries. Low-selectivity fields yield poor results, and array fields may cause index bloat. Regular maintenance is required.

Aggregation operations (count, distinct)

In MongoDB, the count operation is used to count the number of documents in a collection that match specified conditions. The basic syntax is `db.collection.count(query)`. After version 4.0, it is recommended to use `countDocuments` for precise counting or `estimatedDocumentCount` for quick estimation. The distinct operation is used to retrieve distinct values of a field, returning an array result. In the aggregation pipeline, the `$count` stage can be used with other stages to achieve complex statistics, or `$group` can be used to implement functionality similar to distinct. Performance considerations include indexes, collection size, and sharded clusters. In practical applications, count and distinct are commonly used in scenarios like e-commerce order statistics and user analysis. Advanced techniques involve combining multiple aggregation stages to handle complex requirements, though there are limitations on result set size and memory. Alternative solutions include using the `$facet` stage, MapReduce, etc., to process large datasets.

Sorting (sort) and pagination (limit, skip)

In MongoDB, sorting and pagination are core operations. Sorting is implemented using the `sort` method, allowing specification of fields in ascending or descending order, with support for multi-field sorting. Indexes can significantly improve sorting performance. Pagination is achieved using `limit` and `skip`, but `skip` performs poorly with large datasets. An alternative is range queries, such as filtering based on the last record's ID from the previous page. Sorting and pagination are often combined—for example, displaying e-commerce products sorted by price and sales with pagination. For deep pagination, cursor-based pagination can be used. The aggregation pipeline also supports sorting and pagination. To optimize pagination performance, avoid large offsets, leverage covered queries, and employ caching techniques.

Projection and field selection

MongoDB's projection mechanism allows specifying return fields in queries to reduce data transfer volume and improve performance. The basic syntax involves setting inclusion or exclusion field rules in the second parameter of the find method. Inclusion is denoted by 1, and exclusion by 0. Note that, except for the _id field, inclusion and exclusion syntax cannot be mixed. The _id field is returned by default but can be explicitly excluded. For nested documents, dot notation can be used for field filtering. Array elements can be limited using specific operators like $slice. Higher versions of MongoDB support conditional projection using aggregation expressions. Proper use of projection enables covered queries, fetching data directly from indexes to reduce network transfer. Special projection operators like $elemMatch and $ allow precise control over returned array elements. In the aggregation pipeline, the $project stage provides more powerful field control capabilities. In practical applications, projection is commonly used to optimize scenarios like product listings and user permission control. When using projection, note that the server still loads the full document into memory and only filters fields during return. Projection can be combined with other query parameters like sorting and pagination.