2. 为什么要用ShardingJDBC
大约 2 分钟
1. MYSQL海量数据带来的性能问题
根据阿里开发手册， 单表行数超过500W或者单表数据容量超过2G，需要考虑水平分表；根据mysql官网，一个表中列数超过1017列，开发者记住1000列就好，需要考虑垂直分表。即行数和数据容量不够，水平分表，列数不够，垂直分表，如下：
eg: 水平有水平分表和水平分库，垂直有垂直分表(商品表、商品明细表)和 垂直分库(订单库、商品库、用户库)
水平分表涉及的问题有三个：
第一个问题是确定分片策略：
水平分表存在一个无法避免的问题是，需要决定根据哪个字段将一个表拆分为多个表，这就是分片字段，决定使用哪个分片字段、决定如何对目标表分片的就是分片策略，常见的分片策略方案包括：哈希取模分片算法、一致性哈希分片算法(哈希环偏斜)、范围分片算法。
第二个问题是确定分布式ID：
需要额外自定义一个字段来存储全局唯一的主键，即分布式ID，因为mysql的物理主键只能保证在一个表内唯一，水平分表将一个表变为多个表，而这个数据库的水平分表对前端来说是透明的，前端需要做 select *from tablename where 主键列= ‘xxx’** 这种类型操作，不能再用id列，常见的方式是水平分表的每个表增加一个额外的列，用uuid或者雪花算法保证唯一。都能保证唯一性，但是用雪花算法比uuid要好，因为uuid没有任何意义，雪花算法可以存储时间戳。*
第三个问题是引入依赖：
需要让后端Java代码中像操作一个表一样，去操作水平分表之后的多个表，要么在服务端代码中引入Sharding-JDBC依赖，要么是在linux上独立安装ShardingSphere这个中间件，两者的原理是一样的，只是一个在服务端代码层面实现，一个在数据库层面实现。