不在分页中使用offset和limit的原因是什么

这篇文章主要讲解了"不在分页中使用offset和limit的原因是什么"，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习"不在分页中使用offset和limit的原因是什么"吧！

OFFSET和LIMIT有什么问题?

正如我们在上几段中简要探讨的那样，OFFSET和LIMIT非常适合于数据使用量很少甚至没有的项目。

当你的数据库开始收集的数据超过了服务器在内存中的存储量时，问题就出现了，你仍然需要对这些数据进行高性能的分页。

要做到这一点，数据库需要在每次请求分页时执行一次低效的全表扫描(在此期间可能会发生插入和删除，我们不希望数据过时!)。

这意味着，如果你有100.000.000个用户，而你要求的OFFSET是50.000.000，那么它将需要获取所有这些记录(甚至不需要!)，将它们放在内存中，然后才会得到在LIMIT中指定的20个结果。

因此，要在网站上显示这样的分页：

50.000 to 50.020 of 100.000

首先需要获取50.000行，看看这效率低下吗?

你应该使用什么

这是你应该使用的：

这是基于游标的分页。

你应该存储最后接收到的主键(通常是一个ID)和Limit，而不是在本地存储当前offset和limit将其与每个请求一起传递，这样查询最终可能与此类似。

为什么?因为通过显式传递最新的读取行，你可以根据有效的索引键告诉数据库确切从哪里开始搜索，而不必考虑该范围之外的任何行。

以下面的比较为例：

针对我们的优化版本：

接收到的记录完全相同，但是第一个查询花费了12.80秒，第二个查询花费了0.01秒。你能体会到差异吗?

注意事项

为了使游标分页能够无缝地工作，你需要有一个独特的、有顺序的列(或列)，比如一个独特的整数ID，在某些特定的情况下，这可能是一个问题。

和以往一样，我的建议是一定要考虑每个表架构的优缺点，以及你需要在每个表中执行哪种查询。如果你需要在查询中处理大量相关数据，Rick James的"Lists article"文章可能会为你提供更深入的指导。

如果我们手中的问题与没有主键有关，比如我们有一个多对多的关系表，传统的OFFSET/LIMIT的方法在这些情况下总是可以使用的，然而这将重新引入潜在的较慢的查询。因此，我建议在要分页的表中使用自动递增的主键，即使只是出于分页的目的。

感谢各位的阅读，以上就是"不在分页中使用offset和limit的原因是什么"的内容了，经过本文的学习后，相信大家对不在分页中使用offset和limit的原因是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是，小编将为大家推送更多相关知识点的文章，欢迎关注！