创建MONGODB 的索引，属于基本操作，但如果是一个有2T 的 collection 要加一个索引，也属于基本操作，实际上量变产生质变，很多问题的考虑都不在那么简单。

这时可能有有一个声音，有你说的那么麻烦吗？我使用 background：true

不就可以了。并且这样的处理的方式在后台处理，不会对现有的系统产生锁和任务无法处理的问题，缺点就是稍微比前台操作耗时一点。

在创建索引的时候，可以通过下面的语句来查看相关的进度

db.currentOp(true).inprog.forEach(function(op){ if(op.msg!==undefined) print(op.msg) })

在MONGODB 4.2 系统上，在构建过程的开始和结束阶段，索引构建仅对被索引的集合获取独占锁，以保护元数据的更改。

构建过程的其余部分使用后

台索引构建的生成行为，以便在构建期间最大化对集合的读写访问。4.2尽管

有更宽松的锁定行为，但索引构建仍然可以生成高效的索引数据结构。mongodb4.2 系统应该是已经抛弃了 background的参数来创建搜索，

根据一代比一代强的想法，自然是 background 有一些需要改进的地方，新的版本才会进行变动。

在MONGODB 3.4 的时候有一个参数

setParameter:

maxIndexBuildMemoryUsageMegabytes: 1024

这个参数就直接为后台添加索引加速的，如果有足够的内存，

（内存的

与wiretiger 无关），则会加速background 添加索引的速度。

作为复制集，添加索引的的方式也是以命令的方式推送到从节点，

但如果是巨大的collection则很多的建议是，需要以特殊的方式来进行索引

的添加，这点类似有些 MYSQL 大表添加索引或字段的一个过程。

1 将节点从集群中分离

2 在分离的节点添加索引

3 将节点在此加入到集群中

4 将添加索引的从节点替换主节点

5 周而复始，直到索引的集群的节点都添加了索引

当然你要注意你的时间窗口，集群离开的时间不要超过oplog的时间窗口，

否则你就好看了。

所以大collection添加索引，就是一个量变到质变的过程，你需要考虑的

问题

1 你内存的大小，是否能hold 你添加的索引

2 业务上访问度是否是高强度的，如果是，那你及需要考虑上面提到的

方法

3 oplog 的设计大小其实和你以后一些基础操作有关

4 尽量抛弃旧版本，升级到 3.6 及以上的版本，这样可以快速调整

oplog的大小

所以一件看上去不值得一提的加索引的事情，其实如果量大到一定程度，

则考虑和需要分析的问题和量级比较小的时候是不能同日而语的。

ITPub博客

MONGODB 加索引大内存与连锁思维