mongoDB清空表之后任然占用空间？

mongoDB清空表之后任然占用空间，怎么解决？
比如说这个图，清理了占用较大的集合，但是存储大小仍然占用

image.png

我的删除写法

db.collection("collectionName").deleteMany({});

执行后的占用大小

image.png

解决办法：
执行：

db.runCommand({compact:"<collection_name>",force:true})

执行后的占用大小

image.png

原因分析：

compact操作对读写的影响

compact 一个集合，会加集合所在DB的互斥写锁，会导致该DB上所有的读写请求都阻塞；因为 compact 执行的时间可能很长，跟集合的数据量相关，所以强烈建议在业务低峰期执行，避免影响业务。

remove与drop的区别

MongoDB 里删除一个集合里所有文档，有两种方式：

<pre class="layui-code layui-box layui-code-view" data-clipboard-text="<span style="font-family: &quot;times new roman&quot;;">（1）db.collection.remove({}, {multi: true})，逐个文档从 btree 里删除，最后所有文档被删除，但文件物理空间不会被回收
（2）db.collection.drop() 删除集合的物理文件，空间立即被回收</span>

1.  `（1）db.collection.remove({}, {multi: true})，逐个文档从 btree 里删除，最后所有文档被删除，但文件物理空间不会被回收
    （2）db.collection.drop() 删除集合的物理文件，空间立即被回收` 

总的来说，remove 会产生逻辑的空闲空间，这些空间能立即用于写入新数据，但文件占用的总物理空间不会立即回收；通常只要持续在写入数据，有物理空间碎片问题并不大，不需要去 compact 集合，有的场景，remove 了大量的数据后，后续的写入可能并不多，这时如果想回收空间，就需要显式的调用 compact。

3、compact具体做了什么？

Compact 动作最终由存储引擎 WiredTiger 完成，WiredTiger 在执行 compact 时，会不断将集合文件后面的数据往前面空闲的空间写，然后逐步 truancate 文件回收物理空间。每一轮 compact 前，WT 都会先检查是否符合 comapact 条件。

    （1）前面80%的空间里，是否有20%的空闲空间，用于写入文件后面20%的数据
    （2）或者前面90%的空间里，是否有10%的空闲空间，用于写入文件后面10%的数据

如果上面都不满足，说明执行compact肯定无法回收10%的物理空间，此时 compact 就回退出。所以有时候遇到对一个大集合进行 compact，compact立马就返回ok，集合的物理空间也没有变化，就是因为 WiredTiger 认为这个集合没有 compact 的必要。

参考文章：
https://www.ucloud.cn/yun/128168.html