为什么分页如此耗费资源？答案

【问题标题】：Why is pagination so resource-expensive?为什么分页如此耗费资源？
【发布时间】：2010-09-06 23:21:06
【问题描述】：

这是一种似乎有一条奇怪曲线的东西，我想得越多，它就越有意义。在一定程度上，当然。然后对我来说根本没有意义。

愿意开导我吗？

【问题讨论】：

【解决方案1】：

因为在大多数情况下，您必须首先对结果进行排序。例如，当您在 Google 上搜索时，you can view only up to 100 pages of results。他们不会为给定关键字（或关键字组合）按超过 1000 个网站的页面排名进行排序。

分页速度很快。排序很慢。

【讨论】：

【解决方案2】：

这是一个非常模糊的问题。我们需要一个具体的例子来更好地理解这个问题。

【讨论】：

【解决方案3】：

Lubos 是对的，问题不在于您正在分页（这会从线路中获取大量数据），而在于您需要弄清楚页面上实际发生了什么..

您需要分页这一事实意味着存在大量数据。很多数据需要很长时间才能排序:)

【讨论】：

【解决方案4】：

我以为你的意思是pagination of the printed page - 那是我咬牙切齿的地方。我本来打算就收集页面的所有内容，定位（这里有大量的规则，约束引擎很有帮助）和理由进行一段精彩的独白……但显然你在谈论组织网页信息的过程.

为此，我猜是数据库命中。磁盘访问很慢。一旦你把它记在内存中，排序就很便宜了。

【讨论】：

【解决方案5】：

当然，对随机查询进行排序需要一些时间，但如果您在经常使用相同的分页查询时遇到问题，则说明数据库设置有问题（索引不正确/根本没有，内存太少等） . 我不是 db-manager) 或者你做的分页严重错误：

大错特错：例如将select * from hugetable where somecondition; 放入一个数组中，使用array.length 获取页数选择相关索引并丢弃数组-然后对每一页重复此操作……这就是我所说的严重错误。

更好的解决方案是两个查询：一个只获取计数，另一个使用limit 和offset 获取结果。（一些专有的、非标准的 sql 服务器可能只有一个查询选项，我不知道）

糟糕的解决方案实际上可能在小表上工作得很好（事实上，在非常小的表上更快并不是不可想象的，因为进行两个查询的开销大于在一个查询中获取所有行。我不是这么说是...）但是一旦数据库开始增长，问题就会变得很明显。

【讨论】：

LIMIT 与大偏移量以及 ORDER BY 或 GROUP BY 的组合仍然可能非常占用资源，这就是为什么 Google 无法获得完整计数（任何超过 1000 个结果的结果） '估计'）也不会在前 1000 个结果之外分页。

【解决方案6】：

这个问题似乎很好地涵盖了，但我会添加一些 MySQL 特有的东西，因为它吸引了很多人：

避免使用SQL_CALC_FOUND_ROWS。除非数据集是微不足道的，否则在两个单独的查询中计算匹配和检索 x 数量的匹配将会快得多。（如果它是微不足道的，那么无论哪种方式你都几乎不会注意到差异。）

【讨论】：

晚餐后随便浏览一下 SO，一个有趣的提示，一个 10 分钟的测试，然后一个 10 分钟的调整，等等，我最重的站点上的数据库负载减半！谢谢！
这是一个很好的提示。在另一个查询中进行计数可以在不获取行数据的情况下进行计数，并且可能只使用索引。但是，它在 InnoDb 中是否像在 MyIsam 中一样有效？我有一种有趣的感觉，它有所不同，但可能是错误的。