为什么要分库分表？
【性能角度】分库分表就是为了解决由于数据量多大而导致数据库性能下降的问题：
目的：使得单一数据库、单一数据表的数据量变小，从而提升数据库性能。
【可用性角度】防止单机故障
分库分表包含了分库、分表两部分。在生产中通常包括：垂直分库、水平分库、垂直分表、水平分表。
定义：将一个表按照字段分成多个表，每个表存储其中一部分字段。
场景：表的记录并不多，但是字段却很长，表占用空间很大，检索表的时候需要执行大量的IO，严重降低了性能。
如下图，是一个记录商品信息的表，共包含五个字段（商品ID、商品名称、商品价格、商品图片、商品描述）
在实际的项目当中，展现给用户次数最频繁的字段应该是 商品名称、图片以及价格 等；而对于 商品描述 的信息，只有在用户对商品感到有兴趣并进行点击详情的操作时，用户才会看到该字段的信息。因此在这种情境下，我们可以将 商品描述 这种占用空间较多，但访问不频繁的字段单独拆开来：
像上图所示，将 商品描述 字段，拆开成为另一个表作为辅助表，并且在拆分出来的表中，增加一个记录主表主键ID的字段，当用户对该商品感兴趣并点击查看详情时，就可以主表的主键与该字段匹配，找到对应的 商品描述，并呈现给用户。
通过 垂直分表 性能确实能够得到一定的提升，但是因为 存储的数据始终限制在一台服务器上，服务器的物理硬件存在性能瓶颈（如：IO、磁盘、CPU等），而通过库内垂直分表只解决了单一表数据量过大的问题，但没有将表分布到不同服务器上，因此每个表还是竞争同一个物理机的 CPU、内存、IO等。
定义：垂直分库是指 按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上
核心思想：专库专用
例如，在一个库中，存在四张表：地理区域、店铺信息、商品信息、商品描述。
基于垂直分库的思想，我们把关于商品类的表（商品信息、商品描述）单独放在一个库中（部署到服务器1），把 店铺信息 表放入另一个库中（部署到服务器2），而 地理区域 表属于公共表。
但是，垂直分库并没有解决但表数据量过大的问题！
功能：解决了 单库 数据量过大问题
定义：把同一个表的数据按照一定规则拆分到不同的数据库中，每个库可以放在不同服务器上
经过垂直分库后，数据库性能问题得到一定程度的解决，但是随着业务量的增长，PRODUCT_DB(商品库) 单库存储数据已经超出预估。粗略估计，目前有 8w 店铺，每个店铺平均 150 个不同规格的商品，再算上增长，那商品数量得往 1500w+ 上预估，并且 PRODUCT_DB(商品库) 属于访问 非常频繁 的资源，单台服务器已经无法支撑。此时该如何优化？
可尝试水平分库，将店铺 ID 为单数的和店铺 ID 为双数的商品信息分别放在两个库中。
通过水平分库后，各个库保存的表结构是一样的，但表中的内容是不一样的。
但是，由于同一个表被分配在不同的数据库，需要额外进行数据操作的路由工作，因此大大提升了系统的复杂度。
解决 单表 数据量大的问题
定义：在同一个数据库内，把同一个表的数据按照一定规则拆分到多个表中
按照水平分库的思路对他把 PRODUCT_DB_X(商品库) 内的 表也可以进行水平拆分，其目的也是为解决单表数据量大的问题。
分库 可能 导致执行一次事务所需的数据分布在 不同服务器上，数据库层面无法实现事务性操作，需要更上层业务引入分布式事务操作，难免会给业务带来一定复杂性，那么要想解决事务一致性问题一般有两种手段：
分库分表会导致常规聚合查询操作，如 group by，order by 等变的异常复杂。需要复杂的业务代码才能实现上述业务逻辑，其常见操作方式有：
groupby，orderby 字段存储到一个单一库表（可以是REDIS、ES、MYSQL）中，业务代码中先到单一表中根据查询条件查询出相应数据，然后根据查询到的主键 ID，到分库分表中查询详情进行返回。2次查询操作难点会带来接口耗时的增加，以及极端情况下的数据不一致问题。在数据库表设计时，经常会使用自增 ID 作为数据主键，这就导致后续在迁库迁表、或者分库分表操作时，会 因为主键的变化或者主键不唯一产生冲突，要解决主键不唯一问题。有如下方案：