MySQL 数据库拆分

单体项目在构建之初，数据库的负载和数据量都不大，所以不需要对数据库做拆分。

小型财务系统、文书系统、ERP 系统、OA 系统，用一个 MySQL 数据库实例基本就够用了。

但是随着数据量的飞速增长，一个MySQL的实例已经不够用了。

随之而来的就到了数据库的优化：分库分表、分布式… …

水平拆分

一条记录一条记录切断分出来

• 优点
  • 表关联基本能够在数据库端全部完成
  • 不会存在某些超大型数据量和高负载的表遇到瓶颈的问题
  • 应用程序端整体架构改动相对较少
  • 事物处理相对简单
  • 只要切分规则能定义好，基本上较难遇到扩展性限制
• 缺点
  • 切分规则相对更为复杂，很难抽象出一个能满足整个数据库的切分规则
  • 后期数据的维护难度有所增加，人为手工定位数据更为困难
  • 应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难

---

垂直拆分

把常用的，不常用的，字段很长的拆出来

- 拆分规则 - 把不常用的字段单独放在一个表 - 把 text,blob 等大字段拆分出来放在附表中 - 经常组合查询的列放在一张表中 - 优点 - 数据库的拆分简单明了，拆分规则明确 - 应用程序模块清晰明确，整合容易 - 数据维护方便易行，容易定位 - 缺点 - 部分表关联无法再数据库级别完成，需要在程序中完成 - 对于访问极其频繁且数据量超大的表仍然存在性能瓶颈，不一定满足需求 - 事务处理相对更为复杂 - 切分达到一定程度后。扩展性会遇到限制 - 过度切分可能会带来系统过度复杂而难以维护

---

拆分顺序

1、数据分片

• 随着数据量的增加，首先做数据分片
  • 利用多块硬盘来增大数据 IO 能力和存储空间，这么做的成本是最低的
  • 几块硬盘的钱就能收获不错的 IO 性能。

2、水平拆分

• 数据量继续增大，把数据切分到多个 MySQL 节点上，用 MyCat 管理数据切分
• 处理MySQL的读写分离
• 在做水平拆分的同时，业务系统可以引入负载均衡、分布式架构等
• 理论上，冷热数据分离之后，水平拆分可以维持蛮久的，做好定期归档就好了

3、垂直拆分

• 数据库到了水平切分的阶段，数据量的增加已经不是更改架构设计的主要原因了
• 反而是业务系统承受不住了，所以按照模块和业务，把一个系统拆分成若干子系统
• 若干子系统之间，数据相对独立 ==> 垂直切分，把数据表归类，拆分成若干个数据库系统。

如果过早的对数据库做了垂直切分，势必要重新构建若干独立的业务系统，工作量太巨大

水平切分并不需要业务系统做大幅度的修改，因此说应该先从水平切分开始做