我有相当大的数据库，大约有 260 万个文档，其中我有两个集合，每个集合 120 万个，其余的是小集合（<1000 个文档）。当我为小型集合创建新索引时，索引需要很长时间才能完成（所以临时索引没用）。似乎 RavenDB 索引进程读取 DB 中的每个文档并检查是否应将其添加到索引中。我认为只索引索引使用的集合会更好。
此外，当使用 Smuggler 导出数据并且我只想导出一个小集合时，它会读取所有文档并且导出可能需要很长时间。同时使用 RavenDB Linq API 和索引的自定义应用程序可以在几秒钟内导出数据。
为什么 RavenDB 会这样？也许有一些配置设置可能会改变这种行为？
RavenDB 实际上并没有任何真正的“集合”概念。所有文件都差不多。它只是查看Raven-Entity-Name每个文档中的元数据以确定如何将事物组合在一起，以便按类型查询并在管理工作室中显示“集合”页面。
我不确定这样做的具体理由。我认为这与文档存储使用的底层 ESENT 表有关。也许Ayende可以回答得更好。您的特定用例很好地说明了为什么它可能会以不同的方式完成。
您可以尝试的一件事是使用多个数据库。您可以将大量文档放在一个数据库中，而将其他所有文件放在另一个数据库中。当然，您可能会遇到索引相关文档、multi-map/reduce 或其他需要将不同类型的文档放在同一个数据库中的场景的问题。
似乎我的问题的答案即将出现在 RavenDB 3.0 中。Ayende 说：
在 RavenDB 2.x 中，您仍然需要为索引所有内容支付全价，但在 RavenDB 3.0 中并非如此。我们所做的是有效地优化流程，这样在这种情况下，我们将预加载所有参与相关集合的文档，并将它们直接发送到索引。
我们通过使用 Raven/DocumentsByEntityName 索引来做到这一点。无论如何，它已经索引了数据库中的所有内容。这是一个不错的小功能，因为它使我们能够真正利用我们很久以前所做的工作。使用一个索引预填充另一个索引是一个巧妙的技巧，我对此非常满意。
这是完整的博客文章：http ://ayende.com/blog/165923/shiny-features-in-the-depth-new-index-optimization