分表
MySQL 的分表是真正的分表，一张表分成很多表后，每一个小表都是完整的一张表，都对应三个文件，一个.MYD数据文件，.MYI索引文件，.frm表结构文件。
分区
一张大表进行分区后，它还是一张表，不会变成多张表，但是存放数据的区块变多了。
分区对业务代码开发来说是透明的。
MySQL5.6 或以上版本，需要使用下面的查询命令：
show plugins;
上面的查询方法会显示所有插件，如果有红色框的记录（ACTIVE），表示支持分区。
分表和分区Partition 比较
分区（Partition）比较简单，由数据库自身维护数据关系。
分表比分区更复杂，但是性能稍微好一点点。
但分表会造成业务代码更复杂，要通过代码指定数据存储到特定的表。
错误的分表操作，容易引发其他问题。
数据库分库(物理层面进行拆分)
跨库Join的问题，虽然可以通过基础表多数据库同步复制来解决，但也增加了复杂度。
不同业务的拆分：编程复杂(根据业务选择对应的数据库)，做关联业务联级操作的时候，有分布式事务的问题。
同一类业务的拆分：编程复杂，尤其在涉及到复杂业务查询时，有可能需要多库多次查询，然后进行结果集合并。
MySQL 分区、分表、分库
1. 分区、分表、分库都可以大幅提升数据库读的性能。
2. 数据库分库可以提升并发写的速度：通过简单的hash取余、日期时间、或业务区域等等，来拆分同一类业务数据（如订单数据）。或者通过不同业务领域，来拆分不同业务数据（商品、客户、订单、采购等等）。
3. 分区最简单，由数据库自身维护数据关系；
分表复杂，需要开发人员指定数据读写在哪张子表；
分库最复杂，除了为对应的数据选择对应的数据库以外，还需要解决跨库的分布式事务问题。
4. 分区、分表、分库并不冲突，比如在读写分离的业务场景，对读的数据库的某些表进行分区或者分表。或者对于一些容易编程的业务表采用分表，编程复杂的业务用分区，都是可行的。
一主多从，读写分离
除了通过MySQL分区、分表、分库来提升性能之外，还可以通过相对比较简单的读写分离来提升性能。
读写分离，同时提升了数据库单机的读和写的能力，主库负责写和极少部分的即时性要求高的读，从而提升写的性能。从数据库只要负责读，通过二进制日志的形式批量写，并保持数据和主库一致，合作分工，同时提升读写的性能
一主多从下，从库是水平扩展了多个数据库来分摊读的请求（即时性要求不高的读请求），以前一台数据库既负责读又负责写，现在多台数据库分摊读的请求。
适用场景：大部分的读操作对数据的实时性要求并没有那么高，一般对时延的容忍在秒级以上。
