MongoDB uses index

Index can improve the performance of the query, if no INDEX,MONGODB must scan the entire collection, starting with the first doc of collection, until the last doc, even if all doc after the first Doc does not meet the query criteria. If there is a suitable index on the collection, for example, the unique index, then MongoDB will not continue to query the other doc after searching for a doc by index key, which greatly improves the query performance.

The index structure of MongoDB is similar to the nonclustered index of the relational db, which is the btree structure, and in each leaf node, the address of the corresponding doc on disk is stored in addition to the index key. In MongoDB, there is no clustered index, so the initial physical storage of collection is related to the order of Doc insertions, and MongoDB stores the doc on disk in the order in which the doc is inserted, The adjacent doc in the Insert order is also adjacent to the physical location of disk, and the doc modification may change the physical storage of the collection, and if Doc's modification does not cause doc size to increase, then Doc will continue to be stored in the original storage space. Without affecting the physical storage of collection, the physical storage of collection changes as soon as the modify operation causes the doc size to increase, causing Doc to move.

One, Doc's move affects the physical storage of collection

If the data modification increases the size of doc so that it cannot continue to be stored in the original storage space, then MongoDB must move it to the end of collection, where the original storage space is idle, causing the doc's storage density to degrade, which can severely affect query performance. Doc's move process is very slow, equivalent to in an atomic operation, the first to do the doc delete operation, after doing the doc insert operation.

The process of Doc move is as follows:

Modify Doc B so that its size increases, and the original position cannot accommodate B,mongodb to move B at the end of the collection. The original storage space is idle.

Second, CREATE index

MongoDB index is btree structure, btee structure is characterized by: query each value to query the number of times fixed, the smallest value is stored on the leftmost leaf node, the larger value is stored on the rightmost leaf node,

MongoDB creates index by default in ascending order of the "_id" field, and the last doc created is on the right side of index. If each query, is the last of the query n doc, then according to the value of "_id" Flashback query, limit before 100, query performance is very fast. You can also create an index manually using the Db.collection.createIndex (keys,option) function by creating a index,mongodb that meets your business needs.

The format of the keys is: {Field:1/-1,,},field is a field of Doc, 1/-1 represents the creation of index:1 in the direction in which field is sorted, and 1 is created in descending order of field.

Db.collection.createIndex (Keys,

1, create the sample data, create index according to the Age word orderby order

The index you create stores the age field in ascending order of age, and in the leaf node, in addition to the age field, the leaf node stores the doc's address (pointer), which locates the appropriate doc and queries for fields other than index key (age). The following statement creates the index name, which is age_1.

 for (i=0;i<10000;i++) {  Db.foo.insert ({"idx": i,name: "User" +1,age:i%90})--CREATE index By age Ascendantdb.foo.createIndex ({age:1})

2. View query plan for queries

In the example, because the query statement does not set Projection,mongodb to return all fields in Doc, because Index:age_1 contains only the age field, the other field must be located in the original doc to obtain, and therefore multiple addressing operations.

Db.foo.find ({age:22}). Explain ("Executionstats")

By setting projection in the query statement and returning only the age field, the Index:age_1 can contain all the fields in the result set, without locating the original doc, improving query performance and reducing disk IO and memory usage, so You should set projection for each result set, and do not return other fields that you do not need, such as the _id field. By searching index, you can get all the field's index is the overwrite index (convered index), and the overwrite index does not need to be located in the original doc.

Db.foo.find ({age:22},{age:1,_id:0}). Explain ("Executionstats")

Three, index and sort

Sorting is a very memory-intensive operation, and in MongoDB, if the sorted intermediate result set size consumes more than 32mb,mongodb of system memory, it will error, rejecting so much data for sorting. 32MB is a threshold, and if the value is exceeded, you must use index to get the sorted dataset.

MongoDB: Whenunable to obtain the sort order from an index, MongoDB would sort the results in memory, which require s, the result set being sorted is less than and megabytes. When the sort operation consumes more than to megabytes, MongoDB returns an error.

By using index to perform a sort operation, the field that is ordered is the same as the prefix field of index key, and if that condition is met, MONGODB returns the result set of the order directly without the need to perform the actual sort operation. For example, if the index key is {age:1,name:1}, if the sort operation is sort ({age:1}), or sort ({age:1,name:1}), which conforms to the index prefix ordering, then the result assembly is returned directly and does not need to be sorted If the sort operation is sort ({name:1}), or sort ({name:1,age:1}), does not conform to the index prefix ordering, the result set still needs to be sorted in memory if memory consumption exceeds 32MB,MONGODB error.

example, index and sort operations that match the prefix sort

Db.foo.find ({age:22}). Sort ({age:1})

Because MongoDB performs a sort operation with index, and MongoDB has strict limits on the memory resources consumed by the sort operation, in creating index, a tradeoff between finding and sorting should be made to make the query more performance if the sort operation is satisfied. When creating index, use {"Sort Key": 1, "Query filter": 1} format is very useful.

Four, index the internal doc

The great thing about MongoDB index is the ability to create index on the inline Doc field, creating a syntax that is consistent with the regular doc, and using dot notation to index the inline doc field of any depth when referencing fields in the inline doc.

For example, the DOC structure is as follows, the contact is an inline doc and the index is created according to the Contact.phone word orderby order.

{name:"U1", Age:+, contact:   {    phone:123    Email:"[email protected] "   }}--CREATE index Db.foo.createIndex ({" Contact.phone ": 1})

Five, Index maintenance

1. View the index created on collection

Use Db.collectionName.getIndexes () to view all the index information on a given collection:

• Key refers to the definition of index key, which consists of two parts: key and the direction of the sort;
• Name is index name;
• NS is namespace;
• V identifies the index version, if the index contains "V": 1, indicating that index is stored in a new format with high performance.

Db.collection.getIndexes ()

2, delete index

Db.collection.dropIndex (Index)

Mode one, delete index by index name

Db.foo.dropIndex ("Age_1")

Mode two, delete index by index key

Db.foo.dropIndex ({age:1})

3, rebuild all index in collection

Db.collection.reIndex ()

The db.collection.reIndex () drops all indexes on a collection and recreates them. This operation is expensive for collections that has a large amount of data and/or a large number of indexes.

Reference doc:

MongoDB CRUD Concepts

Cursor.explain ()

Indexes

MongoDB uses index