代码之家 › 专栏 › 技术社区 › mwilliams

使用will-paginate without:total-entries改进冗长的查询

will-paginate pagination ruby ruby-on-rails

5

mwilliams · 技术社区 · 15 年前

我目前有一个 威尔佩格 使用 PigNATEYBYSQL 方法来生成要分页的集合。我们有一个自定义查询 条目总数 这很复杂,给数据库带来了很大的负载。因此,我们希望从分页中删除所有条目。

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

我们是否显示上一个链接?当然,只有在当前所选内容中显示的记录之前存在记录时,才会出现这种情况。
我们是否显示下一个链接?如果显示集合中的最后一条记录,则不会显示此信息。

从 docs

查询计数行将如果您 Don_t Supply:总条目数。如果你遇到这个问题生成的SQL,您可能希望在您的应用。

所以最终的理想情况是。

删除总条目数,因为这会导致数据库负载过大
一次显示50条记录,使用“下一页/上一页”按钮进行半分页导航,不需要显示所有可用的页码。
仅相应地显示“下一步”按钮和“上一步”按钮

是否有人处理过类似的问题或对解决方案有想法?

1 回复 | 直到 15 年前

1

14

tadman 15 年前

在许多情况下,paginate在计算条目数方面做得非常糟糕,尤其是当涉及到混淆count-sql生成器的连接时。

如果您所需要的只是一个简单的prev/next方法,那么您所需要做的就是尝试从数据库中检索n+1个条目,如果您只得到n个或少于最后一页上的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中执行一个具有小限制的查询所需的时间与偏移量成正比。实际上,数据库引擎读取到特定偏移值之前的所有行,然后返回下一个限制数行,而不是像您预期的那样跳过前面的行。

对于较大的数据集,如果偏移值在100000以上的范围内,您可能会发现性能显著降低。这说明加载第1页非常快,第1000页有点慢,但第2000页非常慢。