数据库切分

千万量级的数据，用 MySQL 要怎么存？

初学者在看到这个问题的时候，可能首先想到的是 MySQL 一张表到底能存放多少条数据？

根据 MySQL 官方文档的介绍，MySQL 理论上限是 (232)2 条数据，然而实际操作中，往往还受限于下面两条因素：

myisam_data_pointer_size，MySQL 的 myisam_data_pointer_size 一般默认是 6，即 48 位，那么对应的行数就是 248-1。
表的存储大小 256TB
那有人会说，只要我的数据大小不超过上限，数据行数也不超过上限，是不是就没有问题了？其实不尽然。

在实际项目中，一般没有哪个项目真的触发到 MySQL 数据的上限了，因为当数据量变大了之后，查询速度会慢的吓人，而一般这个时候，你的数据量离 MySQL 的理论上限还远着呢！

传统的企业应用一般数据量都不大，数据也都比较容易处理，但是在互联网项目中，上千万、上亿的数据量并不鲜见。在这种时候，还要保证数据库的操作效率，我们就不得不考虑数据库的分库分表了。

数据库切分

这样做有两个好处：

1降低单台数据库实例的负载
2可以方便的实现对数据库的扩容

水平切分

原本放在一个 DB 中的 table 现在放在两个 DB 中，观察之后我们发现：

1、两个 DB 中表的个数都是完整的，就是原来 DB 中有几张表，现在还是几张。
2、每张表中的数据是不完整的，数据被拆分到了不同的 DB 中去了。
这就是数据库的水平切分，也可以理解为按照数据行进行切分，即按照表中某个字段的某种规则来将表数据分散到多个库之中，每个表中包含一部分数据。

这里的某种规则都包含哪些规则呢？这就涉及到数据库的分片规则问题了，这个松哥在后面的文章中也会和大家一一展开详述。这里先简单说几个常见的分片规则：

1、按照日期划分：不容日期的数据存放到不同的数据库中。
2、对 ID 取模：对表中的 ID 字段进行取模运算，根据取模结果将数据保存到不同的实例中。
3、使用一致性哈希算法进行切分。
详细的用法，将在后面的文章中和大家仔细说。

垂直切分

切分特点如下：
1、每一个数据库实例中的表的数量都是不完整的。
2、每一个数据库实例中表的数据是完整的。

老实说，在实际项目中，数据库垂直切分并不是一件容易的事，因为表之间往往存在着复杂的跨库 JOIN 问题，那么这个时候如何取舍，就要考验架构师的水平了！

两种切分的优缺点

水平切分
优点
水平切分最大的优势在于数据库的扩展性好，提前选好切分规则，数据库后期可以非常方便的进行扩容。
有效提高了数据库稳定性和系统的负载能力。拆分规则抽象好， join 操作基本可以数据库做。
缺点
水平切分后，分片事务一致性不容易解决。
拆分规则不易抽象，对架构师水平要求很高。
跨库 join 性能较差。

垂直切分
优点
一般按照业务拆分，拆分后业务清晰，可以结合微服务一起食用。
系统之间整合或扩展相对要容易很多。
数据维护相对简单。
缺点
最大的问题在于存在单库性能瓶颈，数据表扩展不易。
跨库 join 不易。
事务处理复杂。
结语
虽然 MySQL 中数据存储的理论上限比较高，但是在实际开发中我们不会等到数据存不下的时候才去考虑分库分表问题，因为在那之前，你就会明显的感觉到数据库的各项性能在下降，就要开始考虑分库分表了。

好了，今天主要是向大家介绍一点概念性的东西，算是我们分布式数据库中间件正式出场前的一点铺垫。