MongoDB的数据最终都要落到磁盘上以文件的形式保存，无论是排查磁盘空间不足，还是评估数据规模，弄清楚当前实例到底有多少数据文件、每个文件占用了多大空间，都是运维和开发中经常遇到的需求。这篇文章就从命令行工具和磁盘目录两个层面，详细介绍查看MongoDB数据文件的方法。
一、通过db.stats命令查看数据文件统计信息
db.stats是查看单个数据库存储情况最直接的命令。连接到mongoshell之后，切换到目标数据库，执行db.stats()，会返回一组JSON格式的统计结果，其中包含数据规模和文件占用的关键指标。
use mydb db.stats()
返回结果中有几个字段需要特别关注。dataSize表示的是未压缩的逻辑数据大小，也就是集合中的文档在内存中的估算体积；storageSize是数据实际落盘后占用的空间，WiredTiger引擎默认使用snappy压缩，所以这个值通常比dataSize小；fileSize则代表为该数据库分配的物理文件总大小，在旧版本的MMAPv1引擎下这个值非常直观，而在WiredTiger引擎下，它反映的是底层文件占用的磁盘空间。
如果想以更友好的单位显示，可以传入缩放参数，例如db.stats(1024*1024)会把字节数换算成MB，方便快速判断数据库的体量。此外还可以只查询部分字段，比如db.stats().fileSize，直接拿到文件总大小这一个数值。
二、通过db.serverStatus查看存储引擎与文件系统信息
db.stats关注的是单个数据库，而db.serverStatus()则从整个实例的维度给出存储相关的统计。执行这个命令后，重点关注storageEngine字段，它会告诉你当前实例使用的存储引擎名称，比如wiredTiger。不同的存储引擎对应完全不同的数据文件组织方式，这也是判断数据文件数量的前提。
db.serverStatus().storageEngine db.serverStatus().wiredTiger
在WiredTiger引擎的输出中，可以找到block-manager相关的统计项，其中"file bytes currently in the cache"等字段反映了文件层面的读写情况。虽然serverStatus更多用于性能分析，但确认存储引擎类型是排查数据文件问题的第一步，因为MMAPv1引擎下数据文件是以namespace文件加递增编号的数据文件组成，而WiredTiger则是每个集合和索引对应独立的.wt文件。
另一个有用的命令是db.serverStatus().wiredTiger["concurrentTransactions"]这类局部查询，可以避免输出过大。对于想了解全实例数据文件总量的场景，还可以结合db.getSiblingNames()遍历所有数据库逐个统计，汇总出整个实例的数据文件占用情况。
三、直接查看磁盘上的数据文件目录
命令行统计的是逻辑信息，真正想数清楚有多少个物理文件，最直接的办法是去dbpath目录下查看。MongoDB的数据目录默认在Linux下是/data/db，Windows下则取决于配置文件中dbPath参数的设置。可以通过配置文件或启动参数确认实际路径。
mongod --config /etc/mongod.conf grep dbPath /etc/mongod.conf ls -lh /data/db/*.wt | wc -l ls -lh /data/db/
在WiredTiger引擎下，数据目录中的文件有明显的命名规律。每个集合对应一个形如collection-xxx--yyyy.wt的文件，每个索引对应一个index-xxx--yyyy.wt文件，此外还有存储引擎自身的元数据文件WiredTiger.wt、WiredTiger.turtle，以及_mdb_catalog.wt、sizeStorer.wt等系统文件。journal日志存放在journal子目录中，负责保证写入的持久性。
统计文件数量时可以用管道命令组合，例如ls /data/db/collection-*.wt | wc -l统计集合文件数量，ls /data/db/index-*.wt | wc -l统计索引文件数量。两者相加再加上系统文件，基本就是完整的数据文件构成。要注意的是，不要在生产环境随意删除这些文件，即使集合已经drop，某些文件也可能因为checkpoint机制暂时存在。
四、数据文件大小与逻辑数据量为什么对不上
很多人会发现，磁盘上文件占用的空间和自己估算的数据量差距很大，这通常是三个原因造成的。第一是压缩，WiredTiger默认使用block压缩，实际落盘的文件往往只有逻辑数据的一半甚至更小。第二是预分配和文件不收缩，WiredTiger文件只会增长不会自动缩小，删除数据后空间会被复用但不会归还操作系统，这也是为什么大量删除文档后文件大小没有变化的原因。
第三个原因是oplog（操作日志），在副本集环境下，local数据库中的oplog.rs集合是一个固定大小的集合，会预先占用配置的存储空间，这部分在db.stats的结果中归属于local库，容易被忽略。
如果确实需要回收磁盘空间，可以在从节点上执行db.collection.compact()压缩集合文件，或者使用initial sync的方式重建副本集成员。老的repairDatabase方式在现代版本中已经不推荐使用，耗时且风险较高。理解了数据文件的构成和查看方法，后续再做容量规划和空间治理就会清晰很多。
mongodb数据文件mongodb存储db.stats修改时间：2026-09-14 13:14:49