mysql 分库分表

垂直拆分

垂直分表

“大表拆小表”。一般是表中的字段较多，将不常用的， 数据较大，长度较长（比如text类型字段）的拆分到“扩展表“。

垂直分库

将表按照业务场景划分为不同的库。可以将库放在不同的数据库服务器上。

水平拆分

水平分表

针对数据量比较大的单表，按照某种规则（RANGE,HASH取模等），切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。不建议采用。

水平分库分表

将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈

水平分库分表切分规则

• range - -从0到10000一个表，10001到20000一个表；
• HASH取模 - - 取id，然后hash取模，分配到不同的数据库上。
• 地理区域 - - 比如按照华东，华南，华北这样来区分业务
• 时间 - - 按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。

分库分表后面临的问题

1. 事务支持
   分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担
2. 跨库join
   分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表， 结果原本一次查询能够完成的业务，可能需要多次查询才能完成。 粗略的解决方法： 全局表：基础数据，所有库都拷贝一份。 字段冗余：这样有些字段就不用join去查询了。 系统层组装：分别查询出所有，然后组装起来，较复杂。

分库分表框架

1. ShardingSphere

• 一套开源的分布式数据库中间件解决方案。
• 有三个产品：JDBC、Proxy、Sidecar。