这似乎是一条奇怪的曲线，我想得越多，它就越有意义。当然在一定程度上。然后这对我完全没有意义。

想启发我吗？

解决方案

回答

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

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

回答

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

回答

Lubos是正确的，问题不在于我们正在分页(这使大量数据脱线)，而是我们需要弄清楚页面上实际发生的情况。

我们需要分页的事实意味着有很多数据。大量数据需要很长时间才能整理:)

回答

我以为意思是打印页面的分页，这就是我要剪牙的地方。我本来要进入一个很棒的独白，内容涉及收集页面的所有内容，定位(此处有大量规则，constrait引擎非常有帮助)和合理性……但是显然我们在谈论的是组织网页信息的过程。

为此，我猜数据库命中率。磁盘访问速度慢。一旦将其存储在内存中，排序就会很便宜。

回答

当然，对随机查询进行排序会花费一些时间，但是如果我们经常使用相同的分页查询时遇到问题，则数据库设置可能有问题(索引编制不正确/根本不正确，内存太少等。我我不是数据库管理员)，或者我们在进行分页时严重错误：

严重错误：例如在有条件的情况下从"巨大表"中选择" *"到数组中以获取array.length的页数，选择相关索引并丢弃数组，然后为每个页面重复此操作……这就是我所说的严重错误。

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

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

回答

这个问题似乎很好解决，但是我要添加一些MySQL特有的东西，因为它吸引了很多人：

避免使用" SQL_CALC_FOUND_ROWS"。除非数据集是微不足道的，否则在两个单独的查询中对匹配进行计数并检索x个匹配项会更快得多。 (如果琐碎，我们几乎不会注意到两者之间的差异。)