我有一个当前实现will_paginate的使用来构建集合paginate_by_sql方法进行分页。 我们有total_entries自定义查询这是非常复杂的，并把我们的数据库大负荷。 因此，我们想干脆从分页削减total_entries。
换言之，代替的“前1 [2] 3 4 5下一个”典型分页显示，我们将简单地像一个“下一个 - 前面的”按钮只。 但是，我们需要知道一些事情。
- 难道我们显示以前的链接？ 如果之前在当前选择显示的条目记录现有的这只会发生，当然
- 难道我们显示下一个环节？ 如果正在显示集合中的最后一个记录，这将不显示
从文档
如果你不提供用于计算行的查询将自动生成：total_entries。 如果您遇到这种生成的SQL的问题，你可能想在你的应用程序进行手动计数。
所以，最终理想的情况如下。
- 取下total_entries计数，因为它在数据库上造成太大的负荷
- 显示50条记录与在半分页一次只使用一个/上一个按钮来浏览和不需要显示所有可用的页码
- 只有相应显示下一个按钮和上一个按钮
有没有人有类似的问题，工作或有想法的决议？
有许多场合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的查询量是成正比的偏移量。 实际上，数据库引擎通过读取导致对特定的所有行偏移值，然后返回NEXT限制的行数，而不是直接跳到正如你所期望。
对于大型数据集，在那里你在10万加范围内的偏移量，你可能会发现性能显著下降。 这将如何体现是，加载页面1速度非常快，1000页是有点慢，但2000页极其缓慢。
