大数据量分页（海量数据分页）的高效实现

 

海量数据分页，已经无法使用数据库自带的分页机制，比如MySQL 的 Limit ，这会导致严重的性能问题， 经过生产环境大数据量千万级数据量分页实现的 的总结，目前为止我 所使用 的大数据量分页机制 有 两条：

 

1.　如果表中存在 连续 的数字列并 为 索引，那么通过页码即可计算出此字段的范围，直接作范围查询即可：

start = (page-1)*pagesize

end = page*pagesize

select * from table where id >start and id <=end

 

2.  对大量数据旧的分页数据，实际上是固定的，变化的仅仅是前面数页。那么将旧数据导出成一个特殊表，直接以页码为索引列，即可快速分页。同时因为新数据不断填充到前面页，故内部页码使用倒序(即超旧的数据，其在数据库中的页码越小，越新的数据其页码不断增长)

 

成功案例：某健康社区门户问答功能的列表页，目前大约共 3000 万主题帖，每页显示 30 条记录，这样大约是 100 万页。将每页要显示的数据作成一个字段，页码 及科室两个字段作 主索引， 因为业务要求要按科室及页码列出主题，同时科室分类存在层次关系，属性子科室的主题，也需要显示在父科室列表中，这样列表的总记录数实际上是超过 3000万的，冗余度大约是 2.5 ，即有 7500 万条记录，每页显示 30 ，即总共大约有 250 万页。现在将数据表重新进行设计，每页要显示的数据，作为一条记录，这样此表仅仅就只有 250 万条记录，也就相当于 250 万条记录的数据表，可胜任 7500 万主题的分页需要。表结构大致如下：
page #当前记录的页码

classid #科室 id

data #当前页要显示的数据  原始主题记录 json 化或 php 序列化后的字符串

 

但此方案的问题就是数据更新及删除的同步问题。 建议是较新数据周期性（如每 4小时 ）地重新整理，旧数据可使用较慢的周期（如每天）速度处理。同时删除帖子时应该先删除帖子内容，再 使用异步队列机制处理数据的同步和更新。 虽然带来维护上的麻烦，但有效地处理了大数据量分页显示的问题 。

 

列表页及帖子页，全部使用伪静态方式提供访问， 最长的内科列表页，已经达到了 30万页。

数据的存储使用三台Dell R610 机器存储，每次对列表页或帖子页的访问，均需要从 MySQL 查询。目前已经胜任每日约 9 00万次访问量。如果有任何疑惑，请联系 [e-mail] 。 如果你有更好的办法，欢迎一起探讨。

评论

5 楼 月影无痕 2013-04-08  

babaoqi 写道

这种方式查询效率很高但如果删除某个问题时，当前page的问题数量就小于 pagesize

这个问题是存在的，但需要作特殊处理

越旧的数据，其页码是越小的，但前台显示则相反，需要程序中作页码反转

比如有30万页，前台page=1, 则在查询数据库时，需要处理成page=30万
前台page=2 查询时实际为page=29万

这样的好处是，新的数据不断填充，并使数据库内部的page不断增长，旧的数据其页码就固定死了。

4 楼 月影无痕 2013-04-08  

linyunxue 写道

删除一条数据后，所有分页数据要重新更新，给服务器带来的消耗更大，不可取吧！

其实，一般来说，越旧的数据，被删除的概率会越小，新数据被删除的概率就大很多

不能使用一刀切的做法，这里就需要将新旧数据区别对待

删除一条新数据，不需要将全部列表页整理一次，比如
最新的1万条数据，每5分钟整理一次
最新的5万条数据，每2小时整理一次
最新的50万，每半天整理一次

最老的数据，每周整理一次即可

依次类推即可

如果删除一条新数据，就没必要把所有老列表全整理一次了

3 楼 linyunxue 2013-04-08  

删除一条数据后，所有分页数据要重新更新，给服务器带来的消耗更大，不可取吧！

2 楼 babaoqi 2012-09-13  

如果问题是按照最后更新时间排序，我说的方式就不适合了，刚才没仔细看清需求，不好意思

1 楼 babaoqi 2012-09-13  

如果查询只会通过 科室，ID查询，由于科室数量是有限的，每个科室建立一张问题表，
问题表的主键是自增ID，并且按照主键进行范围分区

查询某页问题时
算出start = (page-1)*pagesize
select * from table where id >start limit pagesize;
不要使用end条件比较，主键本身有序，不需要做额外的排序操作，找到start的位置后顺序读取pagesize行，效率还是很快的

缺点
不适合查所有问题


疑问：
可胜任 7500 万主题的分页需要。表结构大致如下：
page #当前记录的页码
classid #科室 id
data #当前页要显示的数据  原始主题记录 json 化或 php 序列化后的字符串

这种方式查询效率很高但如果删除某个问题时，当前page的问题数量就小于 pagesize