为什么分页如此资源昂贵？

Question

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

关心开导我？

Answer 1

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

分页很快。排序很慢。

Answer 2

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

您需要页面这一事实意味着有大量数据。许多数据需要很长时间才能排序：）

Answer 3

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

Answer 4

这个问题看起来很清楚，但我会添加一些MySQL特定的东西，因为它会捕获很多人：

避免使用SQL_CALC_FOUND_ROWS。除非数据集是微不足道的，否则计算匹配并在两个单独的查询中检索x个匹配量将会更快。 （如果它 是微不足道的，那么你几乎都不会注意到它们之间的区别。）

Answer 5

我以为你的意思是pagination of the printed page - 这就是我切牙的地方。我打算进入一个关于收集页面所有内容，定位（这里有大量规则，constrait引擎非常有用）和理由的伟大独白...但显然你在谈论组织网页信息的过程。

为此，我猜数据库命中。磁盘访问速度很慢。一旦你在内存中获得它，排序便宜。

Answer 6

当然，对随机查询进行排序需要一些时间，但是如果你遇到常规使用相同分页查询的问题，那么数据库设置有问题（索引不正确/根本没有，内存太少等等）我不是数据库管理员，或者你的分页严重错误：

非常错误：例如将select * from hugetable where somecondition;放入一个数组中，使用array.length选择相关索引并对数组进行分类 - 然后对每个页面重复此操作...这就是我所说的严重错误。

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

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