分布式数据库分库分表,分布式数据库管理系统

跨库连接查询join

如果需要join的数据存在于多个库中，那就比较麻烦，解决的思路有如下几种：

在应用层把原来数据库的Join操作分成多次的数据库操作。在应用层层面上去对数据库进行操作数据冗余，也就是对一些常用的数据进行冗余，这样可以把原来需要Join的数据变为单表查询。这需要结合具体的业务场景借助外部系统解决一些跨库问题 外键约束

外键约束的问题比较难解决，不能完全依赖数据库本身来完成之前的功能了。如果要对分库后的单库做外键约束，就要求分库后的每个单库的数据是内聚的。否则就要靠应用层的判断，容错等方式了。

跨库查询的问题及解决 数据库分库分表的演化

从逻辑上来说，用户信息应该放在一起存储，然而随着数据量，访问量的增加，需要经历分库分表，此时用户信息在物理上是分布在多个数据库的多张表的。也就是如上图所示的一张逻辑上的表对应了多张物理上的表，对这张表的查询就要做跨库跨表的合并了。这个场景和上面讲的跨库Join还不同，跨库join是在不同的逻辑表之间的Join，在分库后这些Join可能需要跨越多个数据库，而我们现在看到的是针对一个逻辑表的查询操作，但因为物理上分到了多个库多个表，因而产生了数据的合并查询

从具体例子看分库分表后查询的问题。

例子：
当我们假设我们将用户信息按照省份来划分时，如果我们去查询多个省的用户信息，那么就需要跨库查询了。在这样的情况下就需要对查询结果在应用上进行合并，这相对比较简单，但是在一些场景下需要进行较为复杂的操作，介绍如下：

排序，即多个来源的数据查询出来后，在应用层进行排序的工作，如果从数据库中查询出来的数据已经是排好序的，那么在应用层就是要对多路数据的归并排序，如果查询出来的数据未排序。就要进行一个全排序。函数处理，即使用Max，Min，Sum，Count等对多个数据来源的值进行相应的函数处理求平均值，从多个数据源进行查询时，需要把SQL改为查询Sum和Count，然后对多个数据来源的Sum进行求和，Count求和之后计算平均值。非排序分页，分为同步等长分页，还是同等比例分页。排序后分页。这是比较复杂的情况，因为每一个数据源中排序后的大小不能预估，所以我们需要在取数据的时候进行多次比较，性能会收到很大影响。因此，在访问量很大的系统中，我们应该尽量避免这种方式。

参考 大型网站系统与Java中间件实践