微服务或soa服务化，可以把一个大系统划分为n个小系统，独自运行，就意味者垂直分库，垂直分库就意味者数据层面的查询需跨库查询，应对的解决方案：
    1.依赖字段较少：字段冗余
 
      A库中的Tab1表需要关联B库中的Tab2表中的字段F, 我们就将字段F冗余到表Tab1中，那么查询时候，Tab1和Tab2就不需要做Join，单独查A库中的Tab1表就可以解决问题。
    这是一个野路子，因为这是违反正常的范式设计的，但在依赖字段较少的情况下还是可以解决问题的，达到空间来换取时间的目的。
    不过这个方法最大的短板在于2点： 
      1. 依赖字段不能太多，2. 数据一致性问题。Tab2中的F字段一但改变，必须要同步到Tab1中，否则就会引起脏数据的问题。所以，需要在业务代码建立必要的同步机制，如果出错，还需要考虑引入人工补偿。

    2. 依赖字段较多：表同步
    在很多场景下，我们字段的依赖是很多的，乃至查询的时候可能需要跨多张表，这个时候方法1就无法直接用了，我们就需要进行表级别的数据同步，可以采用ETL工具来做到跨库的表同步。不过需要注意的是，数据同步不建议实时性过高，否则数据库的性能会受到比较大的影响。所以对于实时性不高的查询要求，表同步还是比较奏效的。

    3.静态字段依赖：数据字典表
      对于不同库中的静态字段，可以建立一张数据字典表，可以将这类表在其他每个数据库中均保存一份，从而避免跨库join查询。如果静态数据表中的某些字段数据需要修改，可以采用一套脚本统一更新。

    4. 服务层代码进行数据组装
       通过各种服务查询到一个数据集，通过代码进行二次组装，然后生成我们需要返回给前端的对象。在实践过程中，对于处理过的查询集，我们可以将它们缓存在我们的分布式缓存中，减少服务间的RPC调用次数和数据库的查询压力。同时，注意设置好过期时间，把控好数据一致性和有效性。
  
     以上就是4种应对跨库Join的思路，实战中，一定是将这4类方案进行组合使用的，同时，需要注意的是，相比这些解决思路，更重要的是表结构的合理设计。否则要彻底解决跨库是很困难的。