ruby-on-rails - 在没有 :total_entries to improve a lengthy query 的情况下使用 will_paginate

Question

我有一个 will_paginate 的当前实现，它使用 paginate_by_sql 方法来构建要分页的集合。我们有一个针对 total_entries 的自定义查询，它非常复杂并且给我们的数据库带来了很大的负载。因此，我们想从分页中完全删除 total_entries。

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

1. 我们是否显示上一个链接？这当然只会发生在当前选择中显示的记录之前存在的记录
2. 我们是否显示下一个链接？如果显示集合中的最后一条记录，则不会显示此内容

来自docs

A query for counting rows will automatically be generated if you don’t supply :total_entries. If you experience problems with this generated SQL, you might want to perform the count manually in your application.

所以最终理想的情况是这样的。

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

有没有人处理过类似的问题或对解决方案有想法？

Answer 1

在很多情况下，will_paginate 在计算条目数量方面做得非常糟糕，尤其是当涉及的连接混淆了计数 SQL 生成器时。

如果您只需要一个简单的 prev/next 方法，那么您需要做的就是尝试从数据库中检索 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

您可以轻松地将它封装在一些模块中，这些模块可以包含在需要它的各种模型中，或者进行 Controller 扩展。

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

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

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

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