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

数据量很小了，无论是IO还是内存开销都已经很小了。可以忽略。
综合以上三种，第三种方式适用于页面的前n页和后n页，因为这个limit的数据量随着页数的增大而增大，
当大到每个切分后的小表的数据量时就转为第二种方式了。
第二种方式适用于页面的第[n+1, totaoPageNum-n]页。
① 问题描述：
优化之前，还是是一条大慢sql查询时，由于数据库排序是稳定排序，
所以当两条记录排序字段值相同时他们在页面上的页码位置是固定的。
优化之后，当并行执行这N条小sql时，由于无法控制这些小sql的先后执行顺序，
导致在web应用中当两条记录的排序字段值相同时在页面上的页码位置是随机的。
② 解决办法：
除了拉标识字段(seller_id)和排序字段(order_count_sum)之外，再取一个unique（id）的字段，当两条记录的排序字段值相同时，
再用这个unique的字段（在卖家监控中这个字段是id）进行第二次排序.这样就解决了排序不稳定的问题。
③ 也许，看到这里会有疑问，为什么不用seller_id？seller_id也是唯一，这样子不是少取id这个字段，减少IO了？
seller_id虽然也是唯一，可以辅助排序，但是不要忘记数据库的排序规则是：
如果两列的值相等，那么序号在前的排在前面，这里的序号就是主键(自动生成， autoincrement),
如果用seller_id的话还是不能保证排序的稳定性，只能用主键id.
把数据库的连接，扫表，计算等资源优先让给用户关注的主要元素，次要元素可等主要元素加载完成之后再加载。
反应在卖家监控页面中，查数据和查页页码的sql语句基本相同，是在竞争同一资源，
所以，需要做一个策略，优先把资源让给查数，数据查完之后再去查页码。
由于多线程取数据并没有从本质上提高数据库性能，所以必须针对大数据量实时统计排序分页查询做限流
我这里打个比方：食堂有6个窗口，物流团队吃饭要买6个菜，平均每买1个菜需要1分钟的时间，
如果派我一个人去一个窗口买的话需要6分钟的时间
假如派6个人分别去6个窗口买这6个菜，只需要1分钟的时间
但是，如果除了物流团队，再来其他5个团队呢，也就是说6个团队每个团队买6个菜共买36个菜，
这样子有的团队先买完，有的团队后买完，但平均时间还是6分钟。本质上没有变化。
所以，对于特定的查询条件，必须进行限流。让每分钟至多有6个团队买菜，这样子能使得情况变得不至于太糟糕。
这一点从目前来看只能是展望了，比如mysql数据库换更为强大的oracle数据库，
或更换InnoDb引擎为其他，或更换SATA硬盘为SSD。。。。。。
相同的查询条件，原来一个页面查询时间由于超过60秒超时了，根据1-6点建议优化之后，查询时间变为2秒至3.5秒之间。
以上就是关于大数据量下的分页解决方法的全部内容，以及大数据量下的分页解决方法的相关内容,希望能够帮到您。

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

推荐阅读

关于节约粮食的名言诗句关于节约粮食的名言和诗句

奋斗励志朋友圈句子励志短句致自己奋斗朋友圈

想发朋友圈表示心情不好的句子心情不好发朋友圈的句子心情短句

贝拉玻尿酸是合法的吗贝拉玻尿酸是进口的还是国产的

核桃仁做菜的菜谱，您知道桃仁脆溜鸡的做法

浅紫色显皮肤黑还是白

库伦旗景点

居家隔离和集中隔离的区别什么情况下要隔离28天

蝉蛹是什么

怎样能丰胸最安全有效