为什么 MongoDB 的 skip() 这么慢而且不好用，而 MySQL 的 LIMIT 这么快？答案

【问题标题】：Why is MongoDB's skip() so slow and bad to use, while MySQL's LIMIT is so fast?为什么 MongoDB 的 skip() 这么慢而且不好用，而 MySQL 的 LIMIT 这么快？
【发布时间】：2023-04-11 11:32:01
【问题描述】：

Mongo 的 skip() 适用于小型集合，但一旦您有几千条记录，它就会开始变慢。

老实说，我很想知道为什么在 NoSQL 数据库中实现一个像样的类似 LIMIT 的函数这么难。

我一直在阅读的唯一“解决方案”是使用基于范围的查询。但在很多情况下，这不是一个可行的解决方案。

【问题讨论】：

只有当你达到 100,000 行时，跳过才会很慢，它并不总是很慢，但是 SQL 可以对隐藏的 AI 索引进行范围查询，MongoDB 不能，它必须读取文档/索引到跳过点

标签： mysql mongodb limit skip nosql

【解决方案1】：

MySQL 的LIMIT 在大偏移时也有类似的挑战。 StackOverflow 中的几个例子：

具有较大跳过/偏移值的限制查询效率的根本问题是，为了使数据库查询达到可以开始返回记录的程度，必须跳过大量索引条目。对于具有活动写入（插入/更新/删除）的数据库，如果您不隔离查询或缓存结果，这也会导致一些有趣的分页副作用。

基于范围的分页是一种更有效的方法，可以利用索引，但正如您所指出的，它可能并不适合所有用例。如果您经常需要跳过数千条记录并且发现这太昂贵，您可能需要调整数据模型、添加一些缓存或在用户界面中添加使用限制。

例如，在 Google 搜索结果中搜索一个通用术语时，可能会有数亿条结果。如果您继续点击页面，您最终会发现 UI 限制为 1,000 个结果（这可能相当于 50-100 个页面，具体取决于过滤了多少结果）。另一种流行的 UI 方法是 Continuous Scrolling，它避免了一些常见的分页问题（尽管会带来其他可用性挑战）。

【讨论】：

【解决方案2】：

我在使用 skip() 时遇到了同样的问题。当我的数据库中的文档较少时一切正常，但当我的文档数超过 10L 时性能开始受到影响。

我必须摆脱跳过，但随后获取特定数量的数据对我来说是一个挑战。下面的博客帮助了我。

https://scalegrid.io/blog/fast-paging-with-mongodb/

【讨论】：