潜在场景如何？

当 MySQL 单表的数据量过大时，数据库的访问速度会下降，“数据量大”问题的常见解决方案是“水平切分”。

MySQL 常见的水平切分方案有哪些？

（1）分库分表；

（2）分区表。

画外音：我 C，没听过分区表，有朋友惊叹。

什么是分库分表？

把一个很大的库（表）的数据分到几个库（表）中，每个库（表）的结构都相同，但他们可以分布在不同的 MySQL 实例，甚至不同的物理机器上，以达到降低单库（表）数据量，提高读写性能的目的。

分库分表有什么缺点？

分库分表往往是业务层实施的，分库分表后，往往需要升级系统：

（1）修改某些 SQL 代码；

（2）丧失某些 SQL 功能。

什么是分区表？

所有数据，逻辑上还在一个表中，但物理上，可以根据一定的规则放在不同的文件中。这是 MySQL5.1 之后支持的功能，业务代码无需改动。

分区表看上去很帅气，为什么大部分互联网公司不使用，而更多的选择分库分表来进行水平切分呢？

分区表的一些缺点，是大数据量，高并发量的业务难以接受的：

（1）如果 SQL 不走分区键，很容易出现全表锁；

（2）在分区表实施关联查询，就是一个灾难；

（3）分库分表，自己掌控业务场景与访问模式，可控；分区表，工程师写了一个 SQL，自己无法确定 MySQL 是怎么玩的，不可控；

画外音：类似于，不要把业务逻辑实现在存储过程，用户自定义函数，触发器里，而要实现在业务代码里一样。

（4）DBA 给 OP 埋坑，容易大打出手，造成同事矛盾；

（5）…

当然，在数据量和并发量不太大，或者按照时间来存储冷热数据或归档数据的一些特定场景下，分区表还是有上场机会的。

画外音：例如，按照时间分区，存储日志。