创建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的大小
所以一件看上去不值得一提的加索引的事情，其实如果量大到一定程度，
则考虑和需要分析的问题和 量级比较小的时候是不能同日而语的。
