Rails Kaminari如何指定total_count分页？优化COUNT查询性能

好消息！Kaminari完全支持你想要的这个功能，用法和你预想的几乎一致，完美替代will_paginate的total_entries参数，能帮你彻底跳过慢得离谱的COUNT查询。

两种实现方式，按需选择： #

1. 直接在视图层指定总数量

这是最直观的方式，和你示例里写的一样，只需要给paginate视图助手传total_count参数就行：

<%= paginate @items, total_count: @category.items_amount %>

这样Kaminari会直接用你提供的items_amount值来计算分页逻辑，完全不会执行默认的COUNT查询，性能提升立竿见影。

2. 控制器层面预先设置总数量

如果你想把逻辑收拢到控制器里，让视图更简洁，可以用Kaminari的with_total_count方法包装你的分页集合：

# 在Category的show控制器动作里
def show
  @category = Category.find(params[:id])
  # 构建分页集合时直接指定总数量
  @items = @category.items.page(params[:page]).per(72).with_total_count(@category.items_amount)
end

之后视图里只需要正常调用paginate即可，它会自动使用你预先设置的总数量：

<%= paginate @items %>

额外建议：确保缓存数值的准确性 #

既然用到了items_amount缓存字段，一定要保证它的数值和实际条目数一致。最省心的方式是用Rails内置的counter_cache自动维护：

# Category模型
has_many :items, counter_cache: :items_amount

# 记得给categories表添加items_amount字段，默认值设为0

这样每当Item被创建或删除时，Rails会自动更新对应Category的items_amount，完全不用手动写回调，既可靠又高效。

这个方案和你用will_paginate的思路完全一致，而且完美适配Kaminari的分页逻辑，刚好解决COUNT查询性能差的问题。

内容的提问来源于stack exchange，提问作者Nikolay Ageev