MongoDB并不是神奇的更快。如果您以相同的方式存储相同的数据，并以完全相同的方式对其进行访问，那么您真的不应该期望结果会大相径庭。毕竟，MySQL和MongoDB都是GPL，因此，如果Mongo中包含一些神奇的更好的IO代码，则MySQL团队可以将其合并到他们的代码库中。
人们看到现实世界中的MongoDB性能主要是因为MongoDB允许您以更适合您的工作负载的不同方式查询。
例如，考虑一种设计，该设计以规范化方式保留了有关复杂实体的许多信息。这可以轻松地使用MySQL（或任何关系数据库）中的数十个表以标准形式存储数据，并需要许多索引来确保表之间的关系完整性。
现在考虑与文档存储相同的设计。如果所有这些相关表都从属于主表（并且经常属于主表），那么您也许可以对数据建模，以便将整个实体存储在单个文档中。在MongoDB中，您可以将其作为单个文档存储在单个集合中。这是MongoDB开始提供卓越性能的地方。
在MongoDB中，要检索整个实体，您必须执行：
- 在集合上进行一次索引查找（假设通过id获取实体）
- 检索一个数据库页面的内容（实际的二进制json文档）
因此，进行b树查找，并读取二进制页面。Log（n）+ 1个IO 如果索引可以完全驻留在内存中，则为1 IO。
在具有20个表的MySQL中，您必须执行：
- 在根表上进行一次索引查找（同样，假设该实体是通过id获取的）
- 对于聚集索引，我们可以假设根行的值在索引中
- 实体pk值的20多次范围查找（希望在索引上）
- 这些可能不是聚集索引，因此一旦我们确定了合适的子行是什么，就进行了20多个相同的数据查找。
因此，即使假设所有索引都在内存中（这比较困难，因为它们的数量是20倍），mysql的总数也大约为20个范围查找。
这些范围查找可能由随机IO组成-不同的表肯定会驻留在磁盘上的不同位置，并且同一实体在同一表的同一范围内的不同行可能不连续（取决于该实体的状态）更新等）。
因此，对于此示例，与MongoDB相比，每个逻辑访问的最终IO数比MySQL多 20倍 。
这是MongoDB 在某些用例中 可以提高性能的方式。
