尝试使用来自大约50亿的数据库的查询来运行数据库转储时，进度条时间似乎表明此转储在任何合理的时间内（100天以上）都不会完成。该查询似乎在0％左右结束后大约22个小时后结束 - 后面的行是metadata.json行。
转储行是：
mongodump -h myHost -d myDatabase -c mycollection --query "{'cr' : {\$gte: new Date(1388534400000)}, \$or: [ { 'tln': { \$lte: 0., \$gte: -100.}, 'tlt': { \$lte: 100, \$gte: 0} }, { 'pln': { \$lte: 0., \$gte: -100.}, 'plt': { \$lte: 100, \$gte: 0} } ] }"
我的最后几行输出是（打字，因为我还没有发布图片。）
[timestamp] Collection File Writing Progress: 10214400/5066505869 0% (objects)
[timestamp] Collection File Writing Progress: 10225100/5066505869 0% (objects)
[timestamp] 10228391 objects
[timestamp] Metadata for database.collection to dump/database/collection.metadata.json
有任何想法可以帮助提高性能，或者为什么要花这么长时间？
答案 0 :(得分：4)
我刚遇到这个问题，问题是mongodump基本上不是很聪明。它正在遍历_id索引，这可能意味着大量的随机磁盘访问。对我来说，转储几个集合，mongodump只是由于光标超时而崩溃。
此处还介绍了此问题：https://jira.mongodb.org/browse/TOOLS-845。然而，这并没有真正提供“工程设计”的伟大解决方案部分。这个索引有可能是有趣的，但我认为在我的情况下，它只是一个足够大的集合，磁盘访问量对我可怜的小Mac Mini来说非常困难。
一个解决方案？关闭写入，然后使用--forceTableScan，这会顺序传递数据，如果您使用的是自定义_id字段，那么这可能比使用_id索引更快（我是）。
文档有点粗略，但它看起来好像正常mongodump行为可能是使用快照遍历_id索引，然后按查询过滤。换句话说，它可能以_id顺序遍历所有50亿条记录，而不是存储数据顺序，即随机地完成查询。因此，您可能更好地构建一个从真实索引读取并直接写入的工具。
对我来说，--forceTableScan已经足够了，这意味着（a）它实际上已成功完成，并且（b）它的速度提高了一个数量级或更快。