分库分表中间件一般采用的就是全局排序法。假如说我们要查询的是
LIMIT X OFFSET y，那么分库分表中间件会把查询改写为LIMIT x+y OFFSET 0，然后把查询请求发送给所有的目标表。在拿到所有的返回值后，在内存中排序，然后根据排序结果找出全局符合条件的目标数据。
接下来可以先从性能问题上刷一个亮点，抓住受影响的三个方面：网络、内存和CPU
这个解决方案的最大问题就是性能不好。
首先是网络传输瓶颈，比如在LIMIT 10 OFFSET 1000这种场景下，如果没有分库分表，只需要传输10条数据；在分库分表的情况下，如果命中了N个表，那么需要传输的是(1000+10)N条数据。而实际上最终我们只会用其中的10条数据，存在巨大的浪费。
其次是内存瓶颈。收到那么多数据之后，中间件需要维持在内存中排序。
CPU也会成为瓶颈，因为排序本身是一个CPU密集的操作。所以在Proxy形态的分库分表中间件里，分页查询一多，就容易把中间件的内存耗尽，引发OOM，又或是CPU 100%。
不过可以通过*归并排序来缓解这些问题。
关键在拿到数据之后，使用归并排序的算法。
在分库分表里，可以使用归并排序算法来给返回的结果排序，也就是说在改写为
LIMIT x+y OFFSET 0之后，每个目标表返回的结果都是有序的，自然可以使用归并排序。在归并排序的过程中，我们可以逐条从返回结果中读取，这意味着没必要将所有的结果一次性放到内存中再排序。在分页的场景下，取够了数据可以直接返回，剩下的数据就可以丢弃了。
前面说了全局查询这个方案的性能很差，那么有没有其他方案呢？
的确有，比如平均分页、禁用跨页查询、换用其他中间件等。不过任何方案都不是十全十美的，这些方案也存在一些难点，有的是需要业务折中，有的处理过程非常复杂。我们先来看第一个需要业务折中的平均分页方案
