你学会了吗 四种不同的分页处置打算

”经常使用mysql limit 分页就行了，分页查问用得着四种写法吗? "

这或许是很多人的想法。确实mysql limit offset是可以胜任分页的，然而另外三种方法在其余场景体现更好。

大家最相熟的就是如下的分页截图，前往总页数、允许页数跳转。

1 Limit Offset分页

例如每页10条，查问第三页 ，mysql limit 局部为：limit 20,10;

前段每次须要指定 每页数量，页数。由后端拼接查问SQL，构建mysql limit 子句。

limit offset 分页有几个个性。

limit offset 成功便捷，然而存在毛病。当发生深度分页时，MySQL 须要扫描少量数据能力找到指定页的数据，形成慢查问 ，参与参与数据库的内存和cpu负载， 假设这个深度分页的QPS比拟高，无疑最终会拖垮数据库。在流量高峰期，假设深度分页的慢查问较多，毫无不懂，会参与其余SQL耗时，影响其余业务场景。

值得说明的是，分页查问必定指定排序形式。假设没有指定排序形式，经常使用分页很难保障数据不会发生重复。 假设真实没有排序字段，可以经常使用主键ID。

我曾经犯过相似失误，在经常使用ElasticSearch交流lucene 做检索时，发现lucene和ElasticSearch前往的结果不时不分歧，排查了很久，才看法到必定指定排序形式，否则经常使用分页查问会造成数据重复。

那么Limit Offset就没有其余形式防止深度分页吗？答案是可以

2 Limit 指定主键Id过滤

假设在查问条件上加上主键Id是不是就可以了呢？

改良前：

   students  xxxx查问条件xxx   id   

改良后:

   students  xxxx查问条件xxx  id lastMinId   id   

改良后在原有的查问条件上 指定了lastMinId，上一轮最小的Id。在查问下一页时，把上一页的最小id 传下去，这样保障后续查到的列表都是小于lastMinId。从源头上参与了查问条件，缩小了mysql的检索范围，每次都只失掉前二十条数据。

这样就居安思危了吗？当然不

这种形式前提条件是排序形式可以指定主键Id，假设依据其余排序形式，就不能这样做了。

这种形式还有其余运行场景吗？最佳的场景就是从下游批量失掉少量数据时，可以依据主键id启动排序，每次选用最大的N条，或最小的N条。

每次查问都降级主键id范围，这样就能防止深度分页，查问所有的数据。

3 HasMore 滚动查问

有的业务场景例如用户App端的购置记载页，用户只能每页滚动查问购置记载，无需知道购置订单总数。针对这个场景，有什么提升呢？

在之前的limit Offset分页时，须要前往记载总数，前端也要确定查问总页数。滚动分页查问则无需失掉总页数，无需查问总数。缩小了一次性select count(*)的查问。

只有要在每一次性分页查问时，每页数量+1 即可。例如每页10条，可以指定11条，假设真查进去11条，hasMore=true，抢先须要继续查，否则hasMore=false，抢先无需再分页查问。

4 ElasticSearch 分页查问

ES 比拟实用于检索条件复杂、实时性要求比拟低的查问场景。例如B端的各类复杂查问条件检索场景以及 C端用户关键词订单列表搜查等场景。查问耗时基本在100ms以上、甚至1s以上。

值得一提的是须要mysql数据异构到ES，ES加载进索引也有1s左右提早，数据从发生到ES索引提早比拟高。

ElasticSearch 允许分页查问，和Mysql Limit offset 相似。同时也剧烈倡导，经常使用分页查问时，指定排序形式。

SearchRequest searchRequest  new SearchRequestSearchSourceBuilder sourceBuilder  new SearchSourceBuilder   pageNum    pageSizesourceBuildersourceBuildersizepageSize

和mysql相似，ES也有深度分页的查问压力，自动的最大查问深度max_result_window=1W， 阈值可以修正。在低频的B端查问场景，可以依据须要适当调整阈值。

以上4种分页查问形式没有最好，须要针对不同的场景选用最适合的。