Sharding-JDBC分库分表，效果究竟有多惊艳？

本文共计5189个文字，预计阅读时间需要21分钟。

各位好，我是本期ShardingSphere专题的第一篇文章，将简要介绍Sharding-JDBC实现分库分表的详细配置。关于分库分表带来的问题和什么是分库分表，这里不再赘述，相信大家已有了解。

大家好，我是不才陈某~

这是《ShardingSphere 进阶》专栏的第一篇文章，介绍一下Sharding-JDBC实现分库分表的详细配置。

分库分表带来的问题

关于什么是分库分表这里不再细说了，相信大家都知道，有不清楚的可以看我之前的文章：​​聊聊分库分表​​

从单一表、单一库切分成多库、多表对于性能的提升是必然的，但是同时也带来了一些问题。

1. 分布式事务问题

由于垂直分库、水平分库，将数据分摊在不同库中，甚至不同的服务器上，势必带来了分布式事务的问题。

对于单库单表的事务很好控制，分布式事务的控制却是非常头疼，但是好在现在已经有成熟的解决方案，想要了解的可以看我之前的文章：​​七种分布式事务解决方案​​

2. 跨节点关联join问题

在切分之前关联查询非常简单，直接SQL JOIN便能解决，但是切分之后数据分摊在不同的节点上，此时JOIN就比较麻烦了，因此切分之后尽量避免JOIN。

解决这一问题的有些方法：

1、全局表

这种很好理解，对于一些全局需要关联的表可以在每个数据节点上都存储一份，一般是一些数据字典表。

全局表在Sharding-JDBC称之为广播表

2、字段冗余

这是一种典型的反范式设计，为了避免关联JOIN，可以将一些冗余字段保存，比如订单表保存userId时，可以将userName也一并保存，这样就避免了和User表的关联JOIN了。