随着数据的日益增多，在架构上不得不分库分表，进步零碎的读写速度，然而这种架构带来的问题也是很多，这篇文章就来讲一讲跨库/表分页查问的解决方案。
架构背景
笔者已经做过大型的电商零碎中的订单服务，在企业初期时业务量很少，单库单表根本扛得住，然而随着时间推移，数据量越来越多，订单服务在读写的性能上逐步变差，架构组也尝试过各种优化计划，比方后面介绍过的：冷热拆散、查问拆散各种计划。虽说晋升一些性能，然而在每日百万数据增长的状况下，也是无济于事。
最终通过架构组的探讨，抉择了分库分表；至于如何拆分，分片键如何抉择等等细节不是本文重点，不再赘述。
在分库分表之前先来拆解一下业务需要：
- C端用户须要查问本人所有的订单
- 后盾管理员、客服须要查问订单信息（依据订单号、用户信息.....查问）
- B端商家须要查问本人店铺的订单信息
针对以上三个需要，判断下优先级，当然首先须要满足C端用户的业务场景，因而最终选用了uid作为了shardingKey
当然抉择uid作为shardingKey仅仅满足了C端用户的业务场景，对于后盾和C端用户的业务场景如何做呢？很简略，只须要将数据异构一份寄存在ES或者HBase中就能够实现，比较简单，不再赘述。
假如将订单表依据hash(uid%2+1)拆分成了两张表，如下图：
假如当初须要依据订单的工夫进行排序分页查问（这里不探讨shardingKey路由，间接全表扫描），在单表中的SQL如下：
select * from t_order order by time asc limit 5,5;这条SQL非常容易了解，就是翻页查问第2页数据，每页查问5条数据，其中offest=5
假如当初t_order_1和t_order_2中的数据如下：
以上20条数据从小到大的排序如下：
t_order_1中对应的排序如下：
t_order_2中对应的排序如下：
那么单表构造下最终后果只须要查问一次，后果如下：
分表的架构下如何分页查问呢？上面介绍几种计划
1. 全局查问法
在数据拆分之后，如果还是上述的语句，在两个表中间接执行，变成如下两条SQL：
select * from t_order_1 order by time asc limit 5,5;select * from t_order_2 order by time asc limit 5,5;将获取的数据而后在内存中再次进行排序，那么最终的后果如下：
能够看到上述的后果必定是不对的。
所以正确的SQL改写成如下：
select * from t_order_1 order by time asc limit 0,10;select * from t_order_2 order by time asc limit 0,10;也就是说，要在每个表中将前两页的数据全副查问进去，而后在内存中再次从新排序，最初从中取出第二页的数据，这就是全局查问法
该计划的毛病非常明显：
- 随着页码的减少，每个节点返回的数据会增多，性能非常低
- 服务层须要进行二次排序，减少了服务层的计算量，如果数据过大，对内存和CPU的要求也十分高
不过这种计划也有很多的优化办法，比方Sharding-JDBC中就对此种计划做出了优化，采纳的是流式解决 + 归并排序的形式来防止内存的适量占用，有趣味的能够自行去理解一下。
2. 禁止跳页查问法
数据量很大时，能够禁止跳页查问，只提供下一页的查询方法，比方APP或者小程序中的下拉翻页，这是一种业务折中的计划，然而却能极大的升高业务复杂度
比方第一页的排序数据如下：
那么查问第二页的时候能够将上一页的最大值1664088392作为查问条件，此时的两个表中的SQL改写如下：
select * from t_order_1 where time>1664088392 order by time asc limit 5;select * from t_order_2 time>1664088392 order by time asc limit 5;而后同样是须要在内存中再次进行从新排序，最初取出前5条数据
然而这样的益处就是不必返回前两页的全副数据了，只须要返回一页数据，在页数很大的状况下也是一样，在性能上的晋升十分大
此种计划的毛病也是非常明显：不能跳页查问，只能一页一页地查问，比如说从第一页间接跳到第五页，因为无奈获取到第四页的最大值，所以这种跳页查问必定是不行的。
3. 二次查问法
以上两种计划或多或少的都有一些毛病，上面介绍一下二次查问法，这种计划既能满足性能要求，也能满足业务的要求，不过绝对后面两种计划了解起来比拟艰难。
还是下面的SQL：
select * from t_order order by time asc limit 5,5;1. SQL改写
第一步须要对上述的SQL进行改写：
select * from t_order order by time asc limit 2,5;留神：原先的SQL的offset=5，称之为全局offset，这里因为是拆分成了两张表，因而改写后的offset=全局offset/2=5/2=2
最终的落到每张表的SQL如下：
select * from t_order_1 order by time asc limit 2,5;select * from t_order_2 order by time asc limit 2,5;执行后的后果如下：
下图中红色局部则为最终后果：
2. 返回数据的最小值
t_order_1：5条数据中最小值为：1664088479
t_order_2：5条数据中最小值为：1664088392
那么两张表中的最小值为1664088392，记为time_min，来自t_order_2这张表，这个过程只须要比拟各个分库第一条数据，工夫复杂度很低
3. 查问二次改写
第二次的SQL改写也是非常简单，应用between语句，终点就是第2步返回的最小值time_min，起点就是每个表中在第一次查问时的最大值。
t_order_1这张表，第一次查问时的最大值为1664088581，则SQL改写后：
select * from t_order_1 where time between $time_min and 1664088581 order by time asc;t_order_2这张表，第一次查问时的最大值为1664088481，则SQL改写后：
select * from t_order_2 where time between $time_min and 1664088481 order by time asc;此时查问的后果如下（红色局部）：
上述例子只是数据偶合导致第2步的后果和第3步的后果雷同，理论状况下个别第3步的后果会比第2步的后果返回的数据会多。
4. 在每个后果集中虚构一个time_min记录，找到time_min在全局的offset
在每个后果集中虚构一个time_min记录，找到time_min在全局的offset，下图蓝色局部为虚构的time_min，红色局部为第2步的查问后果集
因为第1步改后的SQL的offset为2，所以查问后果集中每个分表的第一条数据offset为3（2+1）；
t_order_1中的第一条数据为1664088479，这里的offset为3，则向上推移一个找到了虚构的time_min，则offset=2
t_order_2中的第一条数据就是time_min，则offset=3
那么此时的time_min的全局offset=2+3=5
5. 查找最终数据
找到了time_min的最终全局offset=5之后，那么就能够晓得排序的数据了。
将第2步获取的两个后果集在内存中从新排序后，后果如下：
当初time_min也就是1664088392的offset=5，那么原先的SQL：select * from t_order order by time asc limit 5,5;的后果不言而喻了，向后推移一位，则后果为：
刚好合乎之前的后果，阐明二次查问的计划没问题
这种计划的长处：能够准确地返回业务所需数据，每次返回的数据量都十分小，不会随着翻页减少数据的返回量
毛病也是很显著：须要进行两次查问
总结
本篇文章中介绍了分库分表后的分页查问的三种计划：
- 全局查问法：这种计划最简略，然而随着页码的减少，性能越来越低
- 禁止跳页查问法：这种计划是在业务上更改，不能跳页查问，因为只返回一页数据，性能较高
- 二次查问法：数据准确，在数据分布平衡的状况下实用，查问的数据较少，不会随着翻页减少数据的返回量，性能较高