\_id无序导致B-tree频繁分裂和空间重用不足，引发磁盘碎片、查询变慢及dataSize/storageSize比值骤降；应优先使用有序ObjectId，或分离业务ID与\_id。
为什么批量导入后 _id 无序会导致严重碎片？
MongoDB 默认用 ObjectId 作 _id，它包含时间戳前缀，天然有序。但如果你用 UUID、字符串 ID 或自增数字（尤其从其他系统导出），_id 变成随机或逆序，新文档就无法追加到 B-tree 末尾，而是在中间反复插入——B-tree 节点分裂 + 空间重用不充分 → 磁盘碎片飙升，查询变慢，db.collection.stats() 里 dataSize 和 storageSize 比值可能跌到 0.3 以下。
- 实操建议：导入前统一用
ObjectId生成器重写_id，哪怕只是伪造时间戳部分（如ObjectId(Date.now().toString(16) + "0000000000000000")） - 若必须保留业务 ID，把该字段单独建索引，
_id改用递增整数（需自己维护计数器）或ObjectId，避免索引主键和业务逻辑耦合 - 别依赖
mongorestore --drop清理旧数据后再导入——它不回收磁盘空间，只标记删除；真正释放得用compact命令（需停写或副本集主节点切换）
bulkWrite 的 ordered: false 怎么影响预分配效果？
默认 ordered: true 下，MongoDB 会为整个批次预分配连续内存页；设为 false 后，失败文档跳过，但剩余文档仍按原顺序执行——这看似灵活，实际破坏了写入局部性：驱动可能拆分批次、服务端更难预测写入模式，导致 WiredTiger 缓存命中率下降，预分配策略失效。
- 批量导入时一律用
ordered: true，配合客户端重试失败子集（比如捕获WriteError后单独重发） - 单次
bulkWrite文档数控制在 1000 以内（WiredTiger 默认 page size 4KB，超大会触发额外内存拷贝） - 避免混用
insertOne和updateOne在同一批次里——更新操作需要先查再改，破坏写入流，预分配无效
集合级 collMod 配置对碎片的实际约束力
collMod 只能调整现有集合行为，不能逆转已发生的碎片。比如设 usePowerOf2Sizes: true（已弃用）或 noPadding: true，仅影响后续新文档的 padding 策略，对历史文档无效；而 storageEngine.wiredTiger.collectionConfig.blockCompressor 这类压缩配置，虽能减小 storageSize，但压缩/解压耗 CPU，对导入吞吐反有拖累。
- 新建集合时直接指定
storageEngine: { wiredTiger: { configString: "block_compressor=zstd" } }，比导入后再改更稳妥 - 禁用 padding（
noPadding: true）仅适合文档大小高度稳定场景（如固定 schema 日志），否则小文档挤在一起，大文档一来就得挪位置，反而加剧碎片 -
collMod不支持在线修改validationLevel或validationAction，想加 schema 校验？得重建集合 +mongodump/mongorestore
用 mongoimport 还是驱动 bulkWrite？关键看字段映射复杂度
mongoimport 是纯文本解析工具，遇到嵌套 JSON、日期格式不一致、空字段转 null 等问题时，容易静默失败或类型错乱；而驱动层做 bulkWrite 虽要写几行转换逻辑，却能精确控制每字段的类型、默认值、$setOnInsert 行为，且可复用已有连接池与重试策略。
- CSV/TSV 导入且字段简单 → 用
mongoimport --fields+--type csv，但务必加--stopOnError，别让错一条丢全批 - JSONL（每行一个 JSON）且含嵌套对象 → 必须用驱动，用
JSON.parse()后手动 normalize 字段，例如把"created_at": "2023-01-01"转成new Date() - 无论哪种方式，导入前先在测试库跑
db.collection.explain("executionStats").insertMany([...])看执行计划，确认没意外触发 collection scan
真正卡住性能的往往不是单次写入速度，而是 WiredTiger 的 checkpoint 频率和 journal 刷盘时机——这些参数藏在启动配置里，不在导入命令中体现，容易被忽略。
