分页的话,大家觉得是用偏移量好呢,还是用页码好呢?

这是我发在ruby-china上的讨论帖 http://ruby-china.org/topics/3695

假如记录数量非常巨大,有几十万甚至上百万

分页诸如/page/N这样的链接地址,好处在于(我认为),易于seo,并且有现成插件

但是我发现这种分页形式对于数据库、缓存来说并不友好

数据库方面:pagination主要使用的sql的limit [offset], rows,而limit的方式是取出offset之前的记录再抛弃掉,所以对于大页码来说性能是有损害的。

缓存方面,一般我们使用的都是从最新往后翻页,一页显示X条记录,当有新的记录出现的时候,会形成连续反应,后面的页面全都缓存失效

用户体验方面,如果出现新的记录,老的记录会被顶到后面,那么在翻页的时候,经常可以看到之前已经看到过的文章,对于用户来说很不爽。

如果使用偏移量,比如 domain.com/articles/s/N 这种形式,则可以解决以上三种问题。
如果是按id排序,那么就是 where articles.id < N limit rows

翻页过程中的用户,可以保持原来的翻页链接,并且能够使用缓存,如果有新记录,也不会影响翻页的体验。

但这样的坏处可能在于SEO上出现太多页面

有没有朋友来讨论一下

回复中有朋友指出了:

  1. mongodb的offset存在同样的性能问题
  2. Tim yang 支持使用偏移量 http://timyang.net/web/pagination/
  3. 偏移量在老外那又叫“游标”
  4. 如果排序字段不连续,则无法预测页码是偏移量的劣势

“分页的话,大家觉得是用偏移量好呢,还是用页码好呢?”的6个回复

  1. 之前做过类似的设计。但是对于论坛等等排序都是按照最后回复时间来进行排序,所以需要用时间戳做标记。
    这样就有两个问题,一是没办法跳到指定页面了,只能做“上一页”“下一页”的翻页,每页保存当前到达的时间戳。
    另外一个小问题是时间戳又不是唯一的,还要配合一个id,这样代码逻辑就麻烦一些。

  2. 这个太简单了。免费用户前后翻页,收费用户+SEO可以指定页数跳转。反正后者都是前者的多次处理而已。

  3. 哈哈哈哈,其实这是数据库的不同的结果。比如用PostgreSQL,完全可以limit偏移量的用法,百万、千万依然很平滑的上升。

    说点正经的,就是cache来计算页数,然后用<N limit这样的用法。

发表评论

电子邮件地址不会被公开。 必填项已用*标注