MySQL 分区、分表、分库

分表

MySQL 的分表是真正的分表，一张表分成很多表后，每一个小表都是完整的一张表，都对应三个文件，一个.MYD数据文件，.MYI索引文件，.frm表结构文件。

分区

一张大表进行分区后，它还是一张表，不会变成多张表，但是存放数据的区块变多了。

分区对业务代码开发来说是透明的。

MySQL5.6 或以上版本，需要使用下面的查询命令：

show plugins;

上面的查询方法会显示所有插件，如果有红色框的记录（ACTIVE），表示支持分区。

分表和分区Partition 比较

• 分区（Partition）比较简单，由数据库自身维护数据关系。
• 分表比分区更复杂，但是性能稍微好一点点。
• 但分表会造成业务代码更复杂，要通过代码指定数据存储到特定的表。
• 错误的分表操作，容易引发其他问题。

数据库分库(物理层面进行拆分)

• 跨库Join的问题，虽然可以通过基础表多数据库同步复制来解决，但也增加了复杂度。
• 不同业务的拆分：编程复杂(根据业务选择对应的数据库)，做关联业务联级操作的时候，有分布式事务的问题。
• 同一类业务的拆分：编程复杂，尤其在涉及到复杂业务查询时，有可能需要多库多次查询，然后进行结果集合并。

MySQL 分区、分表、分库

1. 分区、分表、分库都可以大幅提升数据库读的性能。

2. 数据库分库可以提升并发写的速度：通过简单的hash取余、日期时间、或业务区域等等，来拆分同一类业务数据（如订单数据）。或者通过不同业务领域，来拆分不同业务数据（商品、客户、订单、采购等等）。

3. 分区最简单，由数据库自身维护数据关系；

分表复杂，需要开发人员指定数据读写在哪张子表；

分库最复杂，除了为对应的数据选择对应的数据库以外，还需要解决跨库的分布式事务问题。

4. 分区、分表、分库并不冲突，比如在读写分离的业务场景，对读的数据库的某些表进行分区或者分表。或者对于一些容易编程的业务表采用分表，编程复杂的业务用分区，都是可行的。

一主多从，读写分离

除了通过MySQL分区、分表、分库来提升性能之外，还可以通过相对比较简单的读写分离来提升性能。

读写分离，同时提升了数据库单机的读和写的能力，主库负责写和极少部分的即时性要求高的读，从而提升写的性能。从数据库只要负责读，通过二进制日志的形式批量写，并保持数据和主库一致，合作分工，同时提升读写的性能

一主多从下，从库是水平扩展了多个数据库来分摊读的请求（即时性要求不高的读请求），以前一台数据库既负责读又负责写，现在多台数据库分摊读的请求。

适用场景：大部分的读操作对数据的实时性要求并没有那么高，一般对时延的容忍在秒级以上。