MongoDB使用过程中遇到的几个问题

使用MongoDB（版本：3.4.3）有一段时间，将使用过程中遇到的一些问题进行整理。

1.因物业停电导致机房断电，服务器宕机，MongoDB无法重启的问题。
删除数据存放目录下的.lock文件，然后进行启动即可。

2.单点单个collection数据过多，查询性能明显降低的问题。
至今总共经过了两个阶段的优化。

第一阶段：单个collection的数据超过12W时，查询性能明显下降。
经过是这样的，系统上线一段时间后，某一天领导突然告诉我说“今天有员工反应，XX页面突然变慢了，很奇怪昨天都还是很快的”。“是哪几位同事反应说慢的？我去具体问明一下情况”，得知反应问题的同事后，我立即打电话过去问明了情况，并通过测试帐号重现了该问题。随后我打开专用笔记本，连上应用服务器top了一下，发现一切正常。随即ssh到DB服务器top了一下，发现MongoDB对资源的占用相当高（CPU、内存）。MongoDB本身有记录慢查询的功能，但默认是不开启的，恰巧我们MongoDB就没有开启记录功能，所以直接通过DB查看慢查询的路子不通；随后分析了一下慢页面涉及到的collection，发现只有XX collection的数据量较多，通过测试最终确认就是该collection慢导致，随后分析了所有该collection的查询功能，并根据分析的结果在MongoDB中建立索引，问题解决。

第二阶段：单个collection的数据达到130W左右时，查询性能下降明显。
系统上线三年后，某一天，领导又告诉我XX页面突然变慢了，当时一听大概就知道问题所在，立即登上系统并确认了该问题及原因。原来还是某个collection数据过多导致，即使建立索引也不起作用，因为该系统公司员工使用相当频繁，所以如果通过分区来解决的话比较花费比较长的时间，而领导期望是当天就解决该问题，但是现在已经是下午五点多，通过该方法时间上明显来不及。随后去仔细查看了该功能的使用情况，代码，并分析了数据。发现实现上的热点数据是非常少的，大概只占总数据的百分之一点几，不到百分之二，如果将非热点数据从该collection分离，该问题是否就解决了呢？随后分析了该collection涉及的所有功能，发现通过该方法是可行的，说干就干，添加了一个触发器，在热点数据处理完之后，通过该热发器将热点数据转为非热点数据，原程序代码不动，七点半左右代码写完，八点在测试环境OK，八点半上线，完美解决。

3.因硬盘空间不够进行数据迁移的问题。
   这个问题没有啥好说的，mount一个空间比较大的盘，停了应用，没有通过mongodb自带的备份命令备份，因为实在是太慢了，直接通过copy命令把整个dbpath复制到新盘，修改dbpath、logpath后重启MongoDB就OK了。