使用will_paginate而不使用：total_entries可以改善冗长的查询

Question

我目前正在实施 will_paginate ，它使用 paginate_by_sql 方法构建要分页的集合。我们对 total_entries 进行了自定义查询，这非常复杂，并且会对我们的数据库造成很大负担。因此，我们希望完全从分页中删除total_entries。

换句话说，我们只是喜欢“下一个 - 上一个”按钮，而不是“前一个[2] 3 4 5下一个”的典型分页显示。但我们需要了解一些事情。

1. 我们是否显示上一个链接？只有当记录存在于当前选择中显示的记录之前时，才会发生这种情况
2. 我们是否显示下一个链接？如果正在显示集合中的最后一条记录，则不会显示

来自docs

  

计算行的查询将   如果你自动生成   不提供：total_entries。如果你   遇到这个问题   您可能想要生成SQL   在你的手动执行计数   应用

所以最终理想情况如下。

• 删除total_entries次数，因为它会导致数据库负载过重
• 一次只使用下一个/上一个按钮进行半分页显示50条记录，无需显示所有可用的页码
• 仅显示下一个按钮和上一个按钮

是否有人处理类似问题或对决议有何想法？

Answer 1

在很多情况下，will_paginate在计算条目数方面做得非常糟糕，特别是如果涉及的连接会使计数SQL生成器混淆。

如果你需要的只是一个简单的上一个/下一个方法，那么你需要做的就是尝试从数据库中检索N + 1个条目，如果你只得到N或者你在最后一页上。

例如：

per_page = 10
page = 2

@entries = Thing.with_some_scope.find(:all, :limit => per_page + 1, :offset => (page - 1) * per_page)

@next_page = @entries.slice!(per_page, 1)
@prev_page = page > 1

您可以轻松地将其封装在某些模块中，该模块可以包含在需要它的各种模型中，或者进行控制器扩展。

我发现这比默认的will_paginate方法效果要好得多。

唯一的性能问题是MySQL的限制，这可能是一个问题，具体取决于表的大小。

无论出于何种原因，在MySQL中使用小LIMIT执行查询所花费的时间与OFFSET成正比。实际上，数据库引擎会读取导致特定偏移值的所有行，然后返回下一个LIMIT数字行，而不是按预期跳过。

对于大数据集，如果您的OFFSET值在100,000加上范围内，您可能会发现性能显着下降。这将显示如何加载页面1非常快，页面1000有点慢，但页面2000非常慢。