我已经用 10 M 行数据进行了测试。每行有 3 个整数列和 2 个字符串列。首先，我将这些数据导入到单个分片的 mongoDB。我在非索引列上使用 db.table.find() 进行了简单的“where”查询。该查询获取大约需要 7 秒的单行。
在同一硬件上，我将相同的数据加载到内存中的 ac# 列表中。我做了一个 while 循环来扫描所有 10M 数据并做一个简单的相等控制来模拟 where 查询。它只需要大约 650 毫秒，比 MongoDB 快得多。
我有一台 32 GB 的机器，所以 mongodb 对表进行内存映射没有问题。
为什么 mongoDB 慢得多？是因为 mongoDB 将数据保存在难以完全扫描的数据结构中，还是因为内存映射与将数据保存在变量中不同。
正如 Remon 指出的那样，您在此测试中肯定是在将苹果与橙子进行比较。
要了解更多关于该表扫描幕后发生的事情，请在此处阅读 MongoDB 内部。（查看存储模型下）
有一个表示连续磁盘空间的范围的概念。
每个范围都指向一个文档链接列表。
该文档包含 BSON 格式的数据。所以现在你可以想象我们将如何检索数据。
现在，拥有索引的美妙之处恰如其分地显示在右上角。MongoDB 使用 BTree 结构进行导航，速度非常快。
尝试更改您的测试以进行一些热身运行并使用索引。
更新：作为我日常工作的一部分，我做了一些测试来比较 JBoss Cache（内存中的 Java 缓存）与 MongoDB 作为应用程序缓存（针对 _id 的查询）的性能。结果相当可比。
从哪儿开始..
首先测试完全是苹果和橘子。将数据集加载到内存中并对其进行完全的内存扫描绝不等于对任何数据库进行表扫描。
我也敢打赌，您正在对冷数据进行测试，并且 MongoDB 的性能在将热数据交换到内存时显着提高。请注意，MongoDB 不会抢先将数据交换到内存中。当且仅当频繁访问数据（或根本不访问，取决于）时，它才会这样做。实际上，更准确地说操作系统确实如此，因为 MongoDB 的存储引擎是建立在 MMF（内存映射文件）之上的。
所以简而言之，您的测试不是一个好的测试，而且您测试 MongoDB 的方式并没有产生准确的结果。您正在使用 C# 等效项测试理论上的最佳案例，除此之外，它比数据库代码复杂得多。