共计 3384 个字符，预计需要花费 9 分钟才能阅读完成。
随着数据的日益增多，在架构上不得不分库分表，进步零碎的读写速度，然而这种架构带来的问题也是很多，这篇文章就来讲一讲跨库 / 表分页查问的解决方案。
架构背景
笔者已经做过大型的电商零碎中的订单服务，在企业初期时业务量很少，单库单表根本扛得住，然而随着时间推移，数据量越来越多，订单服务在读写的性能上逐步变差，架构组也尝试过各种优化计划，比方后面介绍过的：冷热拆散 、 查问拆散 各种计划。虽说晋升一些性能，然而在每日百万数据增长的状况下，也是无济于事。
最终通过架构组的探讨，抉择了分库分表；至于如何拆分，分片键如何抉择等等细节不是本文重点，不再赘述。
在分库分表之前先来拆解一下业务需要：
- 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; 的后果不言而喻了，向后推移一位，则后果为：
刚好合乎之前的后果，阐明二次查问的计划没问题
这种计划的长处：能够准确地返回业务所需数据，每次返回的数据量都十分小，不会随着翻页减少数据的返回量
毛病也是很显著：须要进行两次查问
总结
本篇文章中介绍了分库分表后的分页查问的三种计划：
- 全局查问法：这种计划最简略，然而随着页码的减少，性能越来越低
- 禁止跳页查问法：这种计划是在业务上更改，不能跳页查问，因为只返回一页数据，性能较高
- 二次查问法：数据准确，在数据分布平衡的状况下实用，查问的数据较少，不会随着翻页减少数据的返回量，性能较高
