performance - 为什么分页如此耗费资源？

Question

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

愿意开导我吗？

Answer 1

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

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

Answer 2

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

您需要分页的事实意味着有很多数据。很多数据需要很长时间才能排序:)

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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