https://www.heckjj.com/index.php zh-cn https://www.heckjj.com/post// Heck <@hecks.tk> Wed, 29 Dec 2021 09:19:25 +0000 https://www.heckjj.com/post// 　当业务垂直拆分出很多业务库的时候，如果都部署在同一个源上（同一个机器节点上），那么这种情况是最好办的，直接库名+表名 join就可以。

二、不在一个节点

当不同的库来自不同的节点，那么就没办法直接join查询了，有以下方式和思路：
1.全局表
　　所谓全局表，就是有可能系统中所有模块都可能会依赖到的一些表。比较类似我们理解的“数据字典”。为了避免跨库join查询，我们可以将这类表在其他每个数据库中均保存一份。同时，这类数据通常也很少发生修改（甚至几乎不会），
　　所以也不用太担心“一致性”问 题。

2.字段冗余
　　这是一种典型的反范式设计，在互联网行业中比较常见，通常是为了性能来避免join查询。字段冗余能带来便利，是一种“空间换时间”的体现。但其适用场景也比较有限，比较适合依赖字段较少的情况。

　　最复杂的还是数据一致性问题，这点很难保证，可以借助数据库中的触发器或者在业务代码层面去保证。当然，也需要结合实际业务场景来看一致性的要求。


3.数据同步
　　定时A库中的tab_a表和B库中tbl_b有关联，可以定时将指定的表做同步。当然，同步本来会对数据库带来一定的影响，需要性能影响和数据时效性中取得一个平衡。这样来避免复杂的跨库查询。笔者曾经在项目中是通过ETL工具来实施的。


4.第三方插件
　　　　1.cobar
　　　　2.MyCAT
　　　　3.shardding-jdbc
]]> https://www.heckjj.com/post//#blogcomment <user@domain.com> Thu, 01 Jan 1970 00:00:00 +0000 https://www.heckjj.com/post//#blogcomment