分库分表后如何进行分页查询

在我们做了分库分表之后，数据会散落在不同的数据库中，这时候跨多个库的分页查询、以及排序等都非常的麻烦。

如果分的库不多，那么我们还可以通过扫表的方式把多个库中的数据都取出来，然后在内存中进行分页和排序。

比如我要查询limit 100,100 的话，有三个库，那我就分别到这三个库中把0 - 200之间的数据都取回来，然后再在内存中给他们排序，之后，再取出第100-200之间的数据。

这种做法非常的麻烦，而且随着偏移量越大，当要分的页很多的时候，可想而知这种方法根本就不靠谱。

网上有很多文章写了几种做法，还起了几个名字，比如全局视野法、二次查询法、业务折衷法的，在我看来，这几种做法根本就都不靠谱，而且只会带来复杂的理解和维护成本，而且没有办法都一定的前提条件限制。

一般来说，在企业中是怎么做的呢？我们还是拿订单的分库分表举例，当我们用买家ID分表之后：

中间件支持: 使用数据库中间件（如Mycat、ShardingSphere）来透明化分库分表操作。这些中间件能够自动处理分页查询请求，将请求路由到正确的分表，并在服务器端完成数据聚合和排序，最终返回所需分页结果。这种方式简化了应用开发，但增加了系统的复杂度。

shardingkey查询

一般来说，买家的订单查询是最高频的，而对于买家来说，查询的时候天然就是可以带买家ID的，所以就可以路由到单个库中进行分页以及排序了。
 

非shardingkey的复杂查询

那除了买家、卖家以外，其他的查询怎么办呢？

一般来说，大型互联网公司用的比较多的方案就是使用分布式数据仓库来实现，也就是说我们会把这些数据同步到像TiDB、PolarDB、AnalyticDB等这些数据库中，或者同步到ES中，然后在这些数据库中做数据的聚合查询。

有人说，都用了MySQL了，还要用这些数据库，那方案也太重了，搞的这么复杂干什么？

那话又说回来了，分库分表，真不建议小公司、小团队用，这玩意本身就是意味着成本高的，又想要简单，又想要高效，又想要没问题？在技术领域，是没有银弹的。

分布式搜索引擎

        :引入Elasticsearch、Sphinx等全文搜索引擎，对数据建立索引。查询时，先通过搜索引擎获取需要的ID列表，再根据ID到实际的分表中获取详细数据。这种方式可以支持复杂的查询和高效的分页，但需要额外维护索引的一致性。

全局查询法

        这是最直接但效率较低的方法。需要从所有分表中查询数据，然后在应用层进行汇总和排序，最后取出所需分页的数据。这种方法随着页码的增加，性能会急剧下降，不适用于大规模数据和高并发场景。

缓存策略

        对于经常访问的分页数据，可以考虑使用缓存技术（如Redis）来存储分页结果，减少对数据库的直接访问。