具体用法：
>use testdb
> db.myCollection.runCommand(‘compact‘);
> db.runCommand({ compact : ‘myCollection‘ });
压缩比率截图：
压缩比率=348160/1044480*100%=33%
compact优点：
1.compact只压缩需要的Collection，压缩期间产生的临时文件会就相对较少，对磁盘剩余空间需求较小；
2.compact去除Collection所在文件的碎片,其重建索引的cost也变小了，对内存的需求也减少；
compact注意点：
1.compact操作是不会释放磁盘空间的，而是把释放的空间继续给MongoDB使用；
2.compact操作进行时会产生对应的锁，使用mongostat可以查看，所以该操作最好在业务量最少下进行；
3.限制集合{Capped Collection}是不需要compact的
官方解释是：compact命令能够重写和重组集合的data和index
格式：
db.runCommand({ compact: <collection name>,force:<boolen> } ) ---红色部分是可选项
compact命令之后写你想要整理的collection名字
force参数用于replica set中primary整理时之用，否则会报错
说明：
在compact期间会阻塞其他针对此collection的操作，所以最好在业务不繁忙的时候进行compact动作；
针对compact完成之后，不同引擎会有不同的磁盘影响
WireTiger引擎：
在此引擎的数据库下，compact会整理碎片，并且释放未使用的磁盘空间给系统
MMAPv1引擎：
在此引擎的数据库下，compact会整理碎片，重建索引，但不会将未使用的空间释放给系统，后续新插入的数据依然可以使用这些空间
在复制集架构下的一些注意：
compact命令不会自动复制到secondary节点执行，compact在每个节点成员中都是独立的，在Primary，secondary中执行时都要使用force参数，
当在secondary的collection上执行compact命令时，此secondary节点会变成RECOVERING状态，且无法提供读操作
在capped collection中不必使用compact命令，因为它本身就是固定空间
