MySQL集群架构（三）：分库分表

前言

之前介绍了mysql集群中的高可用双主模式，本节将介绍缓解数据库压力的分库分表策略。

互联网系统需要处理大量用户的请求。比如微信日活用户破10亿，海量的用户每天产生海量的数量；美团外卖，每天都是几千万的订单，那这些系统的用户表、订单表、交易流水表等是如何处理呢？数据量只增不减，历史数据又必须要留存，非常容易成为性能的瓶颈，而要解决这样的数据库瓶颈问题，“读写分离”和缓存往往都不合适，目前比较普遍的方案就是使用NoSQL/NewSQL或者采用分库分表。

使用分库分表时，主要有垂直拆分和水平拆分两种拆分模式，都属于物理空间的拆分。
分库分表方案：只分库、只分表、分库又分表。
垂直拆分：由于表数量多导致的单个库大。将表拆分到多个库中。
水平拆分：由于表记录多导致的单个库大。将表记录拆分到多个表中。

拆分方式

垂直拆分

垂直拆分又称为纵向拆分，垂直拆分是将表按库进行分离，或者修改表结构按照访问的差异将某些列拆分出去。应用时有垂直分库和垂直分表两种方式，一般谈到的垂直拆分主要指的是垂直分库。

如下图所示，采用垂直分库，将用户表和订单表拆分到不同的数据库中

垂直分表就是将一张表中不常用的字段拆分到另一张表中，从而保证第一张表中的字段较少，避免出现数据库跨页存储的问题，从而提升查询效率。
解决：一个表中字段过多，还有有些字段经常使用，有些字段不经常使用，或者还有text等字段信息。可以考虑使用垂直分表方案。

按列进行垂直拆分，即把一条记录分开多个地方保存，每个子表的行数相同。把主键和一些列放到一个表，然后把主键和另外的列放到另一个表中。

垂直拆分优点

• 拆分后业务清晰，拆分规则明确
• 易于数据的维护和扩展
• 可以使得行数据变小，一个数据块 (Block) 就能存放更多的数据，在查询时就会减少 I/O 次数；
• 可以达到最大化利用 Cache 的目的，具体在垂直拆分的时候可以将不常变的字段放一起，将经常改变的放一起
• 便于实现冷热分离的数据表设计模式

垂直拆分缺点

• 主键出现冗余，需要管理冗余列
• 会引起表连接 JOIN 操作，可以通过在业务服务器上进行 join 来减少数据库压力，提高了系统的复杂度；
• 依然存在单表数据量过大的问题
• 事务处理复杂

水平拆分

水平拆分又称为横向拆分。 相对于垂直拆分，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个表仅包含数据的一部分，如下图所示。

水平分表是将一张含有很多记录数的表水平切分，不同的记录可以分开保存，拆分成几张结构相同的表。如果一张表中的记录数过多，那么会对数据库的读写性能产生较大的影响，虽然此时仍然能够正确地读写，但读写的速度已经到了业务无法忍受的地步，此时就需要使用水平分表来解决这个问题

水平拆分：解决表中记录过多问题。
垂直拆分：解决表过多或者是表字段过多问题。
水平拆分重点考虑拆分规则：例如范围、时间或Hash算法等

水平拆分优点

• 拆分规则设计好，join 操作基本可以数据库做
• 不存在单库大数据，高并发的性能瓶颈
• 切分的表的结构相同，应用层改造较少，只需要增加路由规则即可
• 提高了系统的稳定性和负载能力

水平拆分缺点

• 拆分规则难以抽象
• 跨库Join性能较差
• 分片事务的一致性难以解决
• 数据扩容的难度和维护量极大

日常工作中，我们通常会同时使用两种拆分方式，垂直拆分更偏向于产品/业务/功能拆分的过程，在技术上我们更关注水平拆分的方案

主键策略

在很多中小项目中，我们往往直接使用数据库自增特性来生成主键ID，这样确实比较简单。而在分库分表的环境中，数据分布在不同的数据表中，不能再借助数据库自增长特性直接生成，否则会造成不同数据表主键重复。下面介绍几种ID生成算法

UUID

UUID是通用唯一识别码（Universally Unique Identifier）的缩写，长度是16个字节，被表示为32个十六进制数字，以“ - ”分隔的五组来显示，格式为8-4-4-4-12，共36个字符，例如：550e8400-e29b-41d4-a716-446655440000。UUID在生成时使用到了以太网卡地址、纳秒级时间、芯片ID码和随机数等信息&#