MySQL进阶 - 分表分库

• MySQL进阶 - 分表分库
• 参考资料
• 概述
• 水平拆分
  • 水平拆分 策略
  • 水平拆分 存在的问题及解决方案
• 垂直拆分
• 总结

参考资料

• Mysql 分库分表 (opens new window)

概述

使用分库分表时，主要有垂直拆分和水平拆分两种拆分模式，都属于物理空间的拆分。

• 分库分表方案：只分库、只分表、分库又分表。
• 垂直拆分：由于表数量多导致的单个库大。将表拆分到多个库中。
• 水平拆分：由于表记录多导致的单个库大。将表记录拆分到多个表中。

水平拆分

水平拆分又称为横向拆分，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个表仅包含数据的一部分，通常使用Hash算法去拆分,使得具有相同属性的内容落到同一个数据库中。(hash(key) % NUM_DB)

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

优点：

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

缺点：

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

水平拆分 策略

• 哈希取模：hash(key) % NUM_DB
• 范围：可以是 ID 范围也可以是时间范围
• 映射表：使用单独的一个数据库来存储映射关系

水平拆分 存在的问题及解决方案

1. 事务问题

   • 使用分布式事务来解决，比如 XA 接口。

2. 链接

   • 可以将原来的 JOIN 分解成多个单表查询，然后在用户程序中进行 JOIN。

3. ID 唯一性

   • 使用全局唯一 ID：GUID
   • 为每个分片指定一个 ID 范围
   • 分布式 ID 生成器 (如 Twitter 的 Snowflake 算法)

垂直拆分

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

垂直分库**：按数据库中表的密集程度部署到不同的库中**，例如将原来的电商数据库垂直切分成商品数据库、用户数据库等。

垂直分表**：将一张表中不常用的字段拆分到另一张表中**，从而保证第一张表中的字段较少，避免 出现数据库跨页存储的问题，从而提升查询效率。

优点：

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

缺点：

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

总结

1. 水平拆分：解决表中记录过多问题。

2. 垂直拆分：解决表过多或者是表字段过多问题