背景，随着mongo数据量变大，查询效率变低，要对索引进行优化，所在公司对mongo依赖比较严重，而DBA并不对mongo的权限做控制，所以每个后端开发都有mongo的读写权限，通常每个人各自管理自己的模块的数据。
由于笔者所负责的模块数据增长较快，用户的关键业务数据都存在mongo里面，很快mongo里面的数据就积累到几百万，之前只有一个五个字段的联合索引，所以是时候作死了。。。
本着作死要有条不紊有依有据的原则，在测试数据库接近百万数据量的相同Collection里面进行了实操，阻塞方式加索引简直快的飞起，shell里面结果秒回，实际执行没有监控，但也很快，因为几秒内去测试接口，速度明显提高，这样折腾了几回之后公司qa反映接口响应速度很快，顿时信心爆棚，要上线上大展拳脚。
一个月后，要优化接口的任务下来了，顿时心花怒放，多日的准备终于要看到成果了：
一开始还是很谨慎的，试着加上一个索引，当然时间选择是下班前，这时候客户大多下班，出了事情也能得到本公司运维的及时支持，照着测试环境的步骤，一个一个加，结果没有任何用户感知的情况下索引加成功！本着谨慎的原则，唯一一个与测试环境操作不同的就是后台参数为true，天真的以为这样就可以不影响服务了，正是这个不同导致了灾难，事实上前几个索引的添加确实没什么问题，十几秒就添加成功，精神也逐渐松懈下来，这时，套用凯文哈特的一句话，It‘s about to go down!
加完了该加的索引后，去线上看看效果，结果并不理想，猜想原因是之前的5个键的联合索引影响了查询效率，于是想将其拆开，这样虽然特定的一个接口效率会有所降低，但是却照顾了大多数的接口，于是删除了这个索引，然后开始新建索引，过了一分钟，还没有返回结果，线上各种服务开始各种pending。。。事故发生，并持续了3个小时。
看到这里大家就都明白了，就是删除这个联合索引的时间过早了，因为之前添加的索引没有一个是覆盖了这个联合索引中的某个键值的，更要命的是区区几百万数据，主从同步的话应该会很快，偏偏被我自作聪明的选择了后台建索引。这样就导致删除索引后查询开始变慢，这时在线用户还不少，一定量针对mongo的请求开始积压，在短时间内沾满的主服务的连接池，然后不用mongo的的接口也开始变慢，mongo一看进来了查询，就优先处理查询，索引就迟迟建不完，那么索引就不能被使用，查询就会慢，进入了恶性循环。
最终运维和dba查了各种资料在进行了一次mongo重启后，在两个多小时后，决定停服把原来的索引加回去，这时仍然是后台方式，不到5分钟索引就增长了60%完成了创建，服务恢复。
总结：第一点，数据库的索引操作一定在深夜进行，防止影响服务。第二点，看起来谨慎的后台建索引方式并不是最好的，数据量不大的情况下，阻塞可能更干脆影响更小，在本案中，不到几十秒肯定就能完成前台建立单键索引。最后，手里有权限不代表能操作，以后这种事一定要给DBA做。