# 数据库水平垂直拆分

当数据库量非常大的时候，DB 已经成为系统瓶颈时就可以考虑进行水平垂直拆分了。

## 水平拆分

一般水平拆分是根据表中的某一字段(通常是主键 ID )取模处理，将一张表的数据拆分到多个表中。这样每张表的表结构是相同的但是数据不同。

不但可以通过 ID 取模分表还可以通过时间分表，比如每月生成一张表。
按照范围分表也是可行的:一张表只存储 `0~1000W`的数据，超过只就进行分表，这样分表的优点是扩展灵活，但是存在热点数据。

按照取模分表拆分之后我们的查询、修改、删除也都是取模。比如新增一条数据的时候往往需要一张临时表来生成 ID,然后根据生成的 ID 取模计算出需要写入的是哪张表(也可以使用[分布式 ID 生成器](https://github.com/crossoverJie/Java-Interview/blob/master/MD/ID-generator.md)来生成 ID)。

分表之后不能避免的就是查询要比以前复杂，通常不建议 `join` ，一般的做法是做两次查询。

## 垂直拆分

当一张表的字段过多时则可以考虑垂直拆分。
通常是将一张表的字段才分为主表以及扩展表，使用频次较高的字段在一张表，其余的在一张表。

这里的多表查询也不建议使用 `join` ，依然建议使用两次查询。

## 拆分之后带来的问题

拆分之后由一张表变为了多张表，一个库变为了多个库。最突出的一个问题就是事务如何保证。

### 两段提交

### 最终一致性

如果业务对强一致性要求不是那么高那么最终一致性则是一种比较好的方案。

通常的做法就是补偿，比如 一个业务是 A 调用 B，两个执行成功才算最终成功，当 A 成功之后，B 执行失败如何来通知 A 呢。

比较常见的做法是 失败时 B 通过 MQ 将消息告诉 A，A 再来进行回滚。这种的前提是 A 的回滚操作得是幂等的，不然 B 重复发消息就会出现问题。