分库分表之后怎么进行join操作？

目录

一、应用层join

二、使用数据库中间件

三、数据冗余

四、搜索引擎

---

在我们做了分库分表之后，数据会散落在不同的数据库中，这时候在需要进行跨库或跨表的JOIN操作时，就会比较麻烦。

如果数据被分表后，分散在不同的数据库上面，那么标准的join是要在单库内执行的，所以这就会带来复杂性。还有就是不同的库可能在不同的服务器上面，那么一次join就需要和多个数据库交互，那就会有更多的网络延迟，带来性能问题。

而且，有的时候一次join可能并不是2个库，而可能是多个库，比如订单和用户join，我们要查的用户可能散布在很多个库中，那么一次join就会横跨很多库。

那么如何解决呢？有如下几个方法。

一、应用层join

在应用代码中单独查询各个表，然后在应用层将结果合并。这意味着所有必要的数据被加载到应用服务器的内存中，然后执行类似于join的操作。如：

//先从数据库中查询出要查询的订单列表
List<OrderDO> orders = getOrders();

for(OrderDO orderDO : orders){
    OrderDTO orderDTO= new OrderDTO(orderDO);
    //根据用户ID去users表查询用户名
    String userName = getUserNameByUserId(orderDO.getUserId());
    orderDTO.setUserName(userName);
}

这么做的优点是，灵活，可以跨不同的数据库和表实现。不依赖数据库特性，适用于任何数据库系统。

但是他的缺点也很明显，那就是对应用服务器的内存和处理能力要求较高，尤其是数据量大时。而且网络开销可能增加，性能可能受到影响。

二、使用数据库中间件

在分库分表后，我们也可以使用诸如MyCat、Shardingsphere等数据库中间件来支持分库分表环境下的 JOIN 操作，比如使用shardingsphere的联邦查询功能（这个功能还在完善中，并不是特别建议在生产环境中用）。这些中间件可以理解为一个数据库代理，对应用透明地处理数据分片和查询路由。

这个方案的优点是对应用透明，应用不需要关心数据如何分片。可以较为高效地执行查询优化和数据汇总。缺点就是引入额外的系统复杂性和维护成本。性能和支持的SQL特性可能受限于中间件的能力。

三、数据冗余

还有一种方案，那就是调整分库分表策略，尽量减少需要执行 JOIN 操作的场景，比如通过合理的数据冗余和预聚合来避免跨库查询。

这个方案可以显著减少复杂查询，提升系统性能。减少了跨网络的数据传输。缺点是一致性问题，也会增加存储空间。

但是，这个方案确实是公司里面用的比较多的。很多时候对于一些不常修改的字段，做一些数据冗余是非常方便的，比如用户的真实姓名。

四、搜索引擎

使用Elasticsearch等搜索引擎，也是可以解决跨库JOIN的问题的，尤其是在处理大数据和复杂搜索场景时。

我们可以基于前面宽表的思想，把orders表和users中我们关心的所有字段做成一个文档，如类似以下形式：

{
"userId": "123",
"userName": "CLAY",
"orders": [
    {
    "orderId": "a1",
    "orderDate": "2021-01-01",
    "amount": 100
    },
    {
    "orderId": "b2",
    "orderDate": "2021-02-01",
    "amount": 150
    }
]
}

然后再基于canal等工具，把orders表及users表的变更同步到ES中，这样我们就可以基于ES直接做查询了。