不能直接用，除非确认源库与目标库主版本号一致且无废弃特性；遗留数据因引擎、元数据格式及字段结构差异，需经临时旧版实例中转、JSON清洗、索引重建及权限校准方可安全迁移。
mongodump/mongorestore 能不能直接迁遗留数据？
不能直接用，除非你确认源库和目标库的 MongoDB 主版本号一致（比如都是 5.x 或都是 6.x），且没有使用已被移除的特性（如 --oplog 在 6.0+ 中已弃用）。遗留数据常来自 3.6、4.0 或早期 4.2 版本，这些版本默认使用 MMAPv1 引擎或旧版 WiredTiger 元数据格式，mongorestore 在 6.0 环境下会拒绝加载含废弃字段的 BSON 文件，报错类似 invalid bson type for field 或 unrecognized field 'min'。
实操建议：
- 先在目标环境用相同旧版本 MongoDB 启一个临时实例（如 Docker 运行
mongo:4.2），执行mongorestore，再用mongoexport导出为 JSON，最后用mongoimport导入新版本 - 跳过
--oplog参数——它在遗留迁移中基本无效，反而触发兼容性校验失败 - 加
--forceTableScan：避免 WiredTiger 因元数据损坏跳过某些集合（Ubuntu 20.04 上尤其常见）
字段结构不一致时怎么映射旧文档？
遗留数据常有嵌套深度不一、字段命名随意（如 user_name vs userName）、缺失必要字段（如缺 _id）等问题。硬导会导致插入失败或字段丢失，必须做轻量转换。
实操建议：
- 用
mongoexport导出为 JSON，而不是 BSON：mongoexport --db legacy --collection users --out users.json - 写一个 Python/Node.js 脚本做字段清洗：补全
_id（用ObjectId()或哈希生成）、扁平化嵌套对象、统一命名风格、过滤空值字段 - 导入前验证 JSON 结构：
mongoimport --jsonArray --drop --db newdb --collection users users.json，注意--jsonArray仅在文件是数组格式时才需要
如何避免迁移后索引失效或查询变慢？
遗留库可能建了大量未使用的索引，或用了已弃用的稀疏索引语法；迁移后这些索引不会自动适配新版本引擎，反而拖慢写入、占用磁盘，甚至导致 db.collection.stats() 返回异常。
实操建议：
- 迁移前在源库运行
db.getCollectionNames().forEach(coll => print(coll + ': ' + db[coll].getIndexes().length))，记录各集合索引数量 - 迁移后不要直接
mongorestore --drop，而是先清空集合：db.collection.deleteMany({})，再重建必要索引 - 用
db.collection.createIndex({field: 1}, {background: true})而非前台建索引，避免阻塞业务 - 检查
wiredTiger.engineConfig.cacheSizeGB是否匹配新实例内存——Ubuntu 20.04 默认配置常设为 1GB，但遗留数据量大时需手动调高
跨版本迁移时最容易被忽略的权限细节
Ubuntu 20.04 的 systemd 服务默认以 mongodb 用户运行，而遗留备份文件若由 root 打包（如 tar -cf backup.tar /var/lib/mongodb），解压后文件属主仍是 root，mongorestore 会因无权读取报 Permission denied，错误信息里却完全不提权限问题。
实操建议：
- 备份时就用
sudo -u mongodb mongodump --out /backup/legacy，确保输出目录属主正确 - 恢复前执行
sudo chown -R mongodb:mongodb /backup/legacy，别只改目录不改子文件 - 检查
/etc/mongod.conf中storage.dbPath和systemLog.path是否为绝对路径，且路径存在、可写——Ubuntu 20.04 的 snap 安装方式会把/var/snap/mongodb设为只读，必须换用 APT 安装
