大数据量下的分页解决方法

大数据量下的分页解决方法
大数据量下的分页解决方法:要看你的数据存储是用的什么数据库了 。常用的有mysql , sqlserver , oracle 。没种数据库进行分页的SQL语句不同 。
做大数据分页都是无刷新的技术 , 这里我们选择ajax来实现 。ajax请求地址需要你使用后台代码来实现 , 后台代码除了要返回数据集合还要返回数据的总数量 , 总页数 , 下一页等参数 , 方便选择分页的时候获取数据 。
下面看一下后台代码实现 , sqlserver的分页SQL:selecttop一页数量*from表名where主键notin(selecttop15主键from表名)
mysql的分页语句SQL:select*from表名where主键>10orderbydeptnoascpmitn;
大数据量实时统计排序分页查询并发数较小时的几点建议大数据量实时统计排序分页查询的瓶颈不是函数(count , sum等)执行 , 
不是having, 也不是order by , 甚至不是表join, 导致慢的原因就在于“数据量太大本身”
就是将表划分为M份相互独立的部分,可以是分表 , 也可以是不分表但冗余一个取模结果字段
实际结果是不分表比分表更加灵活 , 只需稍加配置 , 就可以动态切分大表 , 随意更改M的大小 。
将1条慢sql(大于30秒)拆分成为N条查询速度巨快的sql(单条sql执行时间控制在20毫秒以内)
然后再web应用中以适当的线程数去并发查询这些执行时间快的N条小sql再汇总结果
第一步查询中去并发执行这N条小sql, 只取排序字段和标识字段 , 其他字段一律丢弃
汇总结果后定位出当前页面要显示的pageNum条数据 , 再进行第二步查询 , 取出页面上需要展示的所有字段
【大数据量下的分页解决方法】PS:这一点是至关重要的 , 其他几点都可以不看 , 这点是最关键的 。慢慢解释一下:
有三种方式统计所有的记录 , 
a) 第一种方式是把数据库中所有记录(只取排序字段和标识字段并且不做任何sum , count having order by等操作)
全部拉到web应用中 , 在web应用中完成所有的计算
b) 第二种方式是把数据库中所有记录做sum count having等操作之后的所有行数拉到web应用中 , 在web应用中完成剩余计算
c) 第三种方式是把数据库中所有记录做sum count having order by等操作之后把limit后的数据拉到web应用中 , 
在web应用中对limit后的数据再计算
显然 , 第一种方式 数据库什么活都不做只取数据 是不可行的 。以lg_order_count_seller为例 , 1500万行 , 
如果只算id, seller_id和order_count 这三个bigint类型 , 至少需要拉8*3*1500 0000 = 360000000=340M,
拉到内存中之后存储需要8*4*15000000= 460M,这还不算List是的2的n次方这个特点和计算排序等的内存开销 , 
不仅数据库与web应用机器IO扛不住 , 就是应用自身恐怕也要OOM了 。
第二种方式 , 所有记录做sum count having等操作之后,由于是group by seller_id的 , 总得数据量变为100万(就是卖家总数) , 
这样子一来 , 共需要拉8*3*100 0000 = 23M,拉到内存之后 , 需要8*4*100 0000 = 30M, 再算上List是的2的n次方这个特点和
计算排序等的内存开销也不会超过100M, IO的时间和内存开销勉强可以考虑接受 。
第三种方式 , 所有记录做sum count having order by等操作之后把limit后的数据拉到web应用中 , 因为做了limit , 所以 , 

推荐阅读