没有COUNT的Kaminari

Question

Kaminari可以在没有使用COUNT（*）查询命中数据库的情况下工作吗？

我的应用程序数据库非常庞大，计算项目所需的时间比获取项目本身要长得多，从而导致性能问题。

欢迎使用大型数据集的其他分页解决方案的建议。

Answer 1

在不发出SELECT COUNT查询的情况下进行分页

通常，分页器需要知道显示链接的记录总数，但有时我们不需要记录的总数，只需要＆＃34;上一页＆＃34;和＆＃34;下一页＆＃34;链接。对于这种用例，Kaminari提供了without_count模式，该模式创建了一个可分页的集合，而不计算所有记录的数量。当您处理非常大的数据集时，这可能会有所帮助，因为在大型表上计数往往会在RDBMS上变慢。

只需将.without_count添加到您的分页对象：

User.page(3).without_count

在您的视图文件中，您只能使用以下简单的帮助程序，而不是使用功能齐全的paginate帮助程序：

<%= link_to_prev_page @users, 'Previous Page' %>
<%= link_to_next_page @users, 'Next Page' %>

来源：github.com/kaminari

Answer 2

在某些情况下，我们想要想要一个总计数，但又不想为它打数据库—在某些情况下，即使索引良好，我们的COUNT查询也要花费几秒钟

因此，我们已将计数器缓存添加到父表中，使其与触发器保持最新状态，并覆盖Relation对象上的total_count单例：

my_house = House.find(1)
paginated = my_house.cats.page(1)
def paginated.total_count
    my_house.cats_count
end

...，所有需要计数的东西都可以工作，而无需进行查询。

这是不寻常的事情。维护计数器缓存有一些成本。如果您对分页数据做进一步的关系处理，可能会有怪异的副作用。覆盖单例方法有时会使调试陷入噩梦。但是，如果使用得很少且记录良好，则可以以良好的性能获得所需的行为。

Answer 3

嗯，Kaminari或will_paginate需要以某种方式计算总数才能确定要呈现的total_pages。这是不可避免的。我的解决方案是查看数据库查询并尝试优化它。这是要走的路。