在现在的互联网架构中，分库分表是一种非常常见的手段，主要用于解决单表或者单库数据过多而导致的性能问题。
垂直切分在我们的微服务架构中很常见，将数据库根据业务模块进行拆分，业务的逻辑处理都通过服务调用来进行，而不是将逻辑放在数据层面，这样就能降低数据库表与表之间的耦合度。
而水平切分，就是我们通常用来解决数据问题的手段了。将数据库中单表的数据进行切分，分成多张相同的表单，数据按照一定的规则分布到不同的数据库实例中，从而达到降低数据量、提高性能的目的。
使用哪个字段来作为分库的依据呢？
通常情况下，我们会选择主键作为分库的依据，根据一定的算法，将数据均匀的分布到每个数据库实例中，同时，尽量让请求也均匀的分布到每个数据库实例上。
例如：我们将订单表进行了切分，一分为二（DB1、BD2），订单表的主键就是订单ID，我们想要均匀的分布数据的话，我们可以对订单ID进行判断，是单数，我们就放在DB1中，是双数，我们就放到DB2中，这样，我们的数据分布就非常的平均，同时，我们的请求在概率上，也是平均的。
当然，分库依据可以很多，这个可以根据自己的业务场景进行设置，只要明白，我们分库是为了缓解数据库的压力，降低单表的数据量，如果我们分库以后，DB1的数据量和请求数远大于DB2，那么我们分库的意义就不是很大了。
通常情况下，我们的分页查询都是通过时间维度进行排序的。如以下sql：
select * from T order by time offset X limit Y;
但是，分库以后，不同的数据库如何进行查询排序呢？我们就来说一跨库的分页查询方式。
假设，我们现在要查询某张表的第三页数据，每页100条数据，曾经没有分库的时候，我们只需要
select * from T order by time offset 200 limit 100;
但是，分库以后，这第三页的100条数据就有很多种分布方式了。
1）均匀分布（极端情况）
数据非常均匀的分布在两个库中，想要找到第三页的数据，就在两个库中各取50%就好了。
2）全部来自一个库（极端情况）
数据非常不平均的分配到了一个库中，所有的数据都来至于一个库，也就是说，只需要取这个单库的数据就可以了。
3）散乱分布（通常情况）
这种情况下，我们很难知道，第三页的数据应该在不同的库中从第几条开始取数，因为分库后，我们丢失了全局视野。因此，如果我们想要精准的找到目标数据，就必须重新构建全局的视野。
如何重新构建这种全局视野呢？
还是用我们要查询第三页的数据来举例，我们可以将两个库中的第一到第三页的数据全部查询出来，然后在内存中合并后进行排序，再取出第三页的数据。
我们的sql也就发生了变化，从
select * from T order by time offset 200 limit 100;
改为
select * from T order by time offset 0 limit 100+200;
全局视野方式进行查询的好处很明显，就是能够让业务数据绝对精准的返回。但是缺点也是明显，数据的查询量大，而且消耗的内存资源较多，当页码增大的时候，性能会集聚的下降。
如果想要解决全局视野方式的缺点，我们可以做出交互上的一点小牺牲来实现
相信这个分页方式大家都不陌生，但是，这种分页方式确实让我们分库以后的查询难度几何级的提升，如果想要解决跨页查询的问题，我们可以对我们的分页控件进行优化，只保留“上一下”、“下一页”的功能，去掉跳转页的功能。
当禁止跳页以后，我们每次查询后，就能够得到当页最后一次查询结果的时间，我们要查询一个分页中的记录时，是需要查询大于当前时间的100条记录就可以了。
两个数据库中各取100条，然后再汇总排序，这样就能够大大的提升查询的效率，同时也保证了数据的精准。
我们的sql也就改成了
select * from T order by time where time>@preMaxTime limit 100;
使用此方式，我们就不会因为页码增加而出现性能的下降了，只是用户的交互体验会稍差一些了。当然，如果是APP用户，就不用担心这点了，因为APP用户很少使用跳转页的交互方式。
允许精度损失的方式就比较暴力，我们不去管数据的分布问题，只是单纯的每个库中取出50条数据，然后排序展示。
在业务中，可能会出现第二页的部分数据时间上早于第一页的数据，这主要还是根据我们的保存数据时候分分布情况来决定。如果我们存储数据的时候，分布得越平均，这种查询方式得到的结果自然就越精准。
使用这种方式，我们就不需要考虑性能上的问题，也不需要考虑页面跳转和页码的问题，查询的复杂度是最低的，是比较推荐的一种查询方式。
当然，如果你的业务不允许这样的情况出现，还需要满足交互、效率等等各种需求，那么，就只有使用最后一个方式了。
这可以说是解决分库查询的究极武器了，能够保证数据的精准度、查询的效率、用户的交互页面，牺牲的只是小小的性能开销和一些代码难度的上升。
方式其实也不难，假设我们要查询第21页的数据，每页5条。这个时候，我们先假设数据是平均分布的，但是我们在每个库都查询全量的5条数据。也就是：
select * from T order by time offset 100 limit 5;
这时，我们得到的数据可能是这样的。
而两个DB中，最小的时间是1487500001【minTime】，这个时间记录下来。两个DB中各自的最大时间也记录下来，分别是DB1：1487500041【maxTime1】 和 DB2：1487500061【maxTime2】。
这时，我们在使用时间去两个数据库中再次进行查询。
select * from T where time between minTime and maxTime1 order by time;
select * from T where time between minTime and maxTime2 order by time;
由于之前minTime来自于DB1，因此，DB1的数据不会发生变化，但是DB2中的条件被放宽了，因此可能会查询出更多的数据。结果可能如下：
而两个结果集合并以后，相当于就获得了全局视野，也就可以很容易的找出这一页需要的5条数据了。
如果谁还有更好的分库分页查询的方法，也欢迎指教！
评论0
加载中...
