Mongodb Guide (translated) (19th)-developer zone-index (3) index deletion, reconstruction, and version

Create an index in the background

By default, index creation will block other database operations. V1.3.2 and later provide the background index creation function.

Delete Index

Delete all indexes of a specified set:

db.collection.dropIndexes();

Delete a single index:

db.collection.dropIndex({x: 1, y: -1})

Run the following command directly without using helper functions:

// note: command was "deleteIndexes", not "dropIndexes", before MongoDB v1.3.2
// remove index with key pattern {y:1} from collection foo
db.runCommand({dropIndexes:'foo', index : {y:1}})
// remove all indexes:
db.runCommand({dropIndexes:'foo', index : '*'})

Re-Indexing

Rebuilding the index name will recreate all the indexes in the Set:

db.myCollection.reIndex()

Other notes about Indexes

• Mongodb indexes (compared with common strings) are case sensitive.
• When you update an object, if the object uses pre-allocated space to fill in the update, then the index with only the corresponding keyword changed will be updated. This enhances the performance. Note that if the object increases and must be moved, the keywords of all indexes must be updated later, which slows down.
• The index information is saved in the system. indexes collection. Run db. system. indexes. find () to view all index information.

Too many keywords cannot be indexed

The maximum size of an index (the sum of the values) is limited. Currently, it is about 800 bytes. Documents with the field value length (technically the size of the keyword in the index) greater than this size cannot be indexed. You will see a log similar to the following:

...Btree::insert: key too large to index, skipping...

No indexed documents will be returned for queries on this index. You can use special index prompts to force other indexes, or actually no index:

db.myCollection.find({<key>: <value too large to index>}).hint({$natural: 1})

This will be used in this document when the specified field is compared, rather than the index.

Index performance

Index makes access through keywords and sequential access very fast. Keyword updates are also fast, because Mongodb can quickly find this document for updates.

However, remember that the creation of each index adds a certain overhead to the insert and delete operations. In addition to writing data to the set, the keywords must also be added to the B-Tree index. In this way, the index is most suitable for those sets with a read frequency much higher than the write frequency. For write-intensive sets, indexes may have adverse effects in many cases. Most collections are read-intensive, so indexing is a good thing in most situations.

Use sort () When no index is available ()

If the dataset to be returned is small (less than 4 MB), you may use sort () to return ordered data without indexing. In this scenario, it is best to use both limit () and sort ().

Index version

Mongodb2.0 uses a new data structure to store indexes. The index of the new version {v: 1} is 25% less than the index of the old version {v: 0. This usually leads to a significant performance improvement.

Currently, it is compatible with the {v: 0} index. That is to say, you can seamlessly upgrade to MongodbV2.0. however, to get the benefits of the new lattice index, you need to re-create the index.

Convert an existing index to the {v: 1} format

{V: 1} type indexes are used by default for all operations for creating indexes.

• Re-indexing replaces any {v: 0} index with the {v: 1} index.
  • Because a bug exists, do not rebuild the index on the slave node earlier than V2.0.0.
• The compression command converts all indexes in the specified set to the {v: 1} type.
• The index type generated by the slave node of the replication group created in the form of data synchronization from the source node is the same as that of the source node.

In V2.0.1, the following operation will convert the {v: 0} type index to the {v: 1} type:

• The repaire database Command converts all indexes to the {v: 1} type.

Rollback to mongodb versions earlier than v2.0

Although Mongodb v2.0 supports the index format of the old version, the old version does not support the new format. If you need to roll back to an old version, the server can run normally, but the query and other operations involving new indexes will record and return an error. That is to say, You need to rebuild all the indexes you want to use in the old version servers.

Programs later than version 1.8.3 can perceive the index version field, but those earlier than or equal to version 1.8.2 cannot. Therefore, if you review a {v: 1} index to 1.8.2 and rebuild the index, the new index will still be marked as {v: 1}, although it is actually {v: 0 }. then you upgrade to 2.0, although the index is in db. system. indexes is marked as {v: 1}, but it cannot be used. Therefore, if you need to roll back to version earlier than or equal to version 1.8.2, you must delete the index and create it (instead of simply rebuilding it ).

Generate {v: 0} Index

In Mongodb2.0, you can still create {v: 0} indexes. Add the {v: 0} Option to the index creation command. For example, in mongo shell:

> // defaults to a v:1 index
> db.foo.ensureIndex({name:1})
> db.system.indexes.find()
{ "v" : 1, "key" : { "_id" : 1 }, "ns" : "mydb.foo", "name" : "_id_" }
{ "v" : 1, "key" : { "name" : 1 }, "ns" : "mydb.foo", "name" : "name_1" }
> db.foo.dropIndex({name:1})
{ "nIndexesWas" : 2, "ok" : 1 }
> // create a v:0 index
> db.foo.ensureIndex({name:1},{v:0})
> db.system.indexes.find()
{ "v" : 1, "key" : { "_id" : 1 }, "ns" : "mydb.foo", "name" : "_id_" }
{ "v" : 0, "key" : { "name" : 1 }, "ns" : "mydb.foo", "name" : "name_1" }