db.collection.drop() 能删除集合但不保证立即释放磁盘空间；wiredtiger 引擎下会同步删除 .wt 文件、较快回收空间，mmapv1 下仅标记可复用、需 repairdatabase 或重同步。
直接说结论：db.collection.drop() 能删集合，但不保证立即释放磁盘空间；真正释放空间需配合存储引擎行为和后续操作。WiredTiger（默认引擎）下，drop 会删除对应 .wt 文件，磁盘空间通常能较快回收；MMAPv1 引擎下，drop 后仍可能残留碎片，需额外处理。
drop 集合后磁盘空间没变小？先确认引擎类型
WiredTiger 和 MMAPv1 对 drop 的处理逻辑完全不同：
- WiredTiger（MongoDB 3.2+ 默认）：
db.collection.drop()会同步删除底层collection-*.wt和index-*.wt文件，操作系统层面可立即回收空间 —— 这是你最常遇到的“删了就释放”的情况。 - MMAPv1（已弃用，仅旧版本存在）：
drop只标记文件为可复用，不物理删除，storageSize不降，磁盘占用不变 —— 此时必须走repairDatabase或重同步。
查当前引擎：db.serverStatus().storageEngine.name。别猜，执行一下再决定下一步。
为什么 db.collection.drop() 后 df -h 看不到空间释放？
常见原因不是命令没生效，而是文件系统或内核缓存延迟暴露真实释放状态：
-
drop成功后，WiredTiger 会异步清理文件，Linux 的df可能滞后几秒到几十秒（尤其在高 I/O 负载下） - 如果使用 LVM、ZFS 或某些云盘（如 AWS EBS），底层卷未触发 trim/discard，空间不会返还给宿主机
- 检查实际文件是否消失：
ls -lh /data/mongodb/db/yourdb/ | grep collection-，若对应.wt文件已不存在，说明 MongoDB 层已释放，问题出在 OS 或存储层 - 临时缓解：运行
sync && echo 3 > /proc/sys/vm/drop_caches（仅测试环境），强制刷缓存
compact 命令不是用来释放空间的，别乱用
db.runCommand({ compact: "collname" }) 是针对「已存在但被大量删除过」的集合做碎片整理，不是为刚 drop 的集合准备的：
- 它只对**现存集合**生效，对已
drop的集合返回"ns not found" - 在 WiredTiger 上，
compact主要重写数据块、合并空闲 extent，对磁盘总空间影响有限（尤其当集合本身很小或刚清空） - 它会阻塞该 secondary 节点读写（进入
RECOVERING状态），且不能在 mongos 或主节点上安全运行 - 真要压缩活跃集合，优先考虑
replSet中逐个对 hidden secondary 执行，而非主节点
真正需要释放空间时，按场景选动作
不要无脑 drop + 等待，根据你的部署结构和引擎选择路径：
- 单机或非副本集：确认是 WiredTiger →
db.collection.drop()→ 等 30 秒 →df -h查看；若仍没变化，检查文件系统是否支持 discard（mount | grep discard） - 副本集（WiredTiger）：在 primary 上
drop，secondary 自动同步删除文件；观察各节点/data/mongodb/db/yourdb/下对应.wt文件是否消失 - 副本集（MMAPv1 或空间仍卡住）：唯一可靠方式是重同步一个 secondary ——
rs.remove("host:port")→ 关闭该节点 → 清空其dbpath→ 重启并rs.add()触发初始同步 - 分片集群：必须登录每个 shard 的
mongod（非mongos），对对应库下的集合分别drop；config server 不参与数据文件释放
最后提醒：drop 不可逆，且 storageSize 和 size 的差值（storageSize - size）才是你当前的碎片量——别只盯着 df，用 db.runCommand({ collStats: "coll" }) 看真实物理占用。
