MySQL 分库分表

1.分库

垂直分库

以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。

水平分库

以字段为依据，按照一定策略（hash、range 等），将一个库中的数据拆分到多个库中。

2.分表

垂直分表

以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。

水平分表

以字段为依据，按照一定策略（hash、range 等），将一个表中的数据拆分到多个表中。

3.水平分表的路由方式

（1）范围路由

选取有序的数据列 （例如，整形、时间戳等） 作为路由的条件，不同分段分散到不同的数据库表中。

优点：可以随着数据的增加平滑地扩充新的表。

缺点：分布不均匀，假如按照 1000 万来进行分表，有可能某个分段实际存储的数据量只有 1000 条，而另外一个分段实际存储的数据量有 900 万条。

（2）Hash 路由

选取某个列 （或者某几个列组合也可以） 的值进行 Hash 运算，然后根据 Hash 结果分散到不同的数据库表中。

Hash 路由的优缺点和范围路由基本相反。

优点：表分布比较均匀。

缺点：扩充新的表很麻烦，所有数据都要重分布。

4.分库分表带来的问题

分库

（1）事务的问题

使用关系型数据库，有很大一点在于它保证事务完整性。

而分库之后单机事务就用不上了，必须使用分布式事务来解决。

注意

在同一个mysql实例下，跨库是可以join的，通过mysql的内部xa事务支持跨库的操作在同一事务中。

（2）跨库 JOIN 问题

在一个库中的时候我们还可以利用 JOIN 来连表查询，而跨库了之后就无法使用 JOIN 了。

解决方案就是在业务代码中进行关联，也就是先把一个表的数据查出来，然后通过得到的结果再去查另一张表，然后利用代码来关联得到最终的结果。

这种方式实现起来稍微比较复杂，不过也是可以接受的。

还有可以适当的冗余一些字段。比如以前的表就存储一个关联 ID，但是业务时常要求返回对应的 Name 或者其他字段。这时候就可以把这些字段冗余到当前表中，来去除需要关联的操作。

还有一种方式就是数据异构，通过binlog同步等方式，把需要跨库join的数据异构到ES等存储结构中，通过ES进行查询。

分表

（1）跨节点的 count,order by,group by 以及聚合函数问题

只能由业务代码来实现或者用中间件将各表中的数据汇总、排序、分页然后返回。

数据迁移，容量规划，扩容等问题

数据的迁移，容量如何规划，未来是否可能再次需要扩容，等等，都是需要考虑的问题。

（2）ID 问题

数据库表被切分后，不能再依赖数据库自身的主键生成机制，所以需要一些手段来保证全局主键唯一。

还是自增，只不过自增步长设置一下。比如现在有三张表，步长设置为3，三张表 ID 初始值分别是1、2、3。这样第一张表的 ID 增长是 1、4、7。第二张表是2、5、8。第三张表是3、6、9，这样就不会重复了。

UUID，这种最简单，但是不连续的主键插入会导致严重的页分裂，性能比较差。

分布式 ID，比较出名的就是 Twitter 开源的 sonwflake 雪花算法