MySQL：谈谈你对水平切分和垂直切分的理解

为什么要拆分数据库?

单体项目在构建之初，数据库的负载和数据量都不大，所以不需要对数据库做拆分，小型财务系统、文书系统、ERP系统、OA系统，用一个MySQL数据库实例基本就够用了。

就像《淘宝技术这十年》里面说到的，电商业务的数据量增长飞快，所以最开始的PHP+MySQL的架构已经不能满足实际要求了，于是淘宝想到的第一个办法就是把MySQL替换成Oracle。但是没过了多久，在08年前后，单节点的Oracle数据库也不好用了，于是淘宝终于告别了单节点数据库，开始拆分数据库。从一个节点，变成多个节点。

数据拆分前要先做一些准备工作：

• 第一步：采用分布式缓存redis、memcached等降低数据库的读操作
• 第二步：如果缓存使用过后，数据库访问量还是非常大，可以考虑数据库读、写分离原则
• 第三步：当我们使用读写分离、缓存后，数据库的压力还是很大的时候，这就需要使用到数据库拆分了

数据库拆分原则：就是指通过某种特定的条件，按照某个维度，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面以达到分散单裤（主机）负载的效果

拆分模式： 垂直（纵向）拆分、水平拆分。

垂直拆分：专库专用

什么是垂直拆分

一个数据库由很多表组成，每个表对应着不同的业务，垂直拆分是指按照业务将表分类，分布到不同的数据库上面，这样也就将数据或者说压力分担在不同的库上面了

例子

比如说一个新零售的电商数据库，我们可以把跟商品相关的数据表拆分成一个数据库，然后在这些数据表的基础之上，构建出商品系统。比如用JAVA或者PHP语言，创建出一个商城系统。然后把跟进销存相关的数据表拆分到另外一个数据库上，再用程序构建出仓库系统。

垂直拆分解决了什么问题

垂直拆分可以降低单节点数据库的负载。原来所有数据表都放在一个数据库节点上，无疑所有的读写请求也都发往这个MySQL上面，所以数据库的负载太高。如果一个节点的数据库拆分成多个MySQL数据库，这样就可以有效的降低每个MySQL的负载

垂直拆分不能解决什么问题

垂直节分不能解决的是缩表，比如说商品表无法划分个哪个数据库节点，商品表的记录还是那么多，不管你把数据库垂直拆分得有多细致，每个数据库里面的数据量时没有变化的。

MySQL单表记录超过2000万，读写性能会下降的很快，因此说垂直拆分不能起到缩表的效果。

优缺点

优点：

• 拆分后业务清晰，拆分规则明确
• 系统之间整合或者扩展容易
• 数据维护简单

缺点：

• 部分业务表无法join，只能通过接口方式解决，提高了系统复杂度
• 受每种业务不同的限制存在单裤性能瓶颈，不易数据扩展跟性能提高。
• 事务处理复杂

水平拆分：分库分表

什么是水平拆分

• 相对于垂直拆分的区别是：垂直拆分是把不同的表拆到不同的数据库中，而水平拆分是把同一个表拆到不同的数据库中。
• 相对于垂直拆分，水平拆分不是将表的数据做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中 的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。
• 分库分表需要涉及到对应的SQL路由规则主库备库等，例如：淘宝设计了一套TDDL来解决这些问题，应用端只需配置对应的规则即可，对应用端的没有任何侵入的设计。

一个误解

很多人对水平切分存在误解，以为水平切分出来的数据表必须保存在不同的MySQL节点上。其实水平切分出来的数据表也可以保存在一个MySQL节点上面。不是水平切分一定需要多个MySQL节点。为什么这么说呢？

• MySQL自带一种数据分区的技术，可以把一张表的数据，按照特殊规则，切分存储在不同的目录下。
• 如果我们给Linux主机挂载了多块硬盘，我们完全可以利用MySQL分区技术，把一张表的数据切分存储在多个硬盘上。这样就由原来一块硬盘有限的IO能力，升级成了多个磁盘增强型的IO。

到底是应该先水平还是先垂直？？？？

• 先水平然后垂直的理由

感觉各有道理。但我支持先垂直，然后水平

数据库拆分原则：

• 优先考虑缓存降低对数据库的读操作
• 再考虑读写分离，降低数据库写操作
• 最后开始数据拆分：
  • 先按照业务垂直拆分
  • 在考虑水平拆分：先分库（设置数据路由规则，把数据分配到不同的库中）
  • 最后在考虑分表，单表拆分到数据1000万以内。