这篇文章主要讲解了“不在分页中使用offset和limit的原因是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“不在分页中使用offset和limit的原因是什么”吧！
OFFSET和LIMIT有什么问题?
正如我们在上几段中简要探讨的那样，OFFSET和LIMIT非常适合于数据使用量很少甚至没有的项目。
当你的数据库开始收集的数据超过了服务器在内存中的存储量时，问题就出现了，你仍然需要对这些数据进行高性能的分页。
要做到这一点，数据库需要在每次请求分页时执行一次低效的全表扫描(在此期间可能会发生插入和删除，我们不希望数据过时!)。
| 什么是全表扫描?全表扫描(又名顺序扫描)是指在数据库中进行扫描，顺序读取表中的每一条记录，然后检查遇到的列的条件是否有效。这种类型的扫描被认为是最慢的，因为从磁盘上读取的I/O量很大，包括多次寻找以及昂贵的磁盘到内存的传输。 |
这意味着，如果你有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的原因是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是本站，小编将为大家推送更多相关知识点的文章，欢迎关注！
