百木园随着业务的不断发展，数据库中的数据会越来越多，相应地，单表的数据量也会越到越大，大到一个临界值，单表的查询性能就会下降。
这个临界值，并不能一概而论，它与硬件能力、具体业务有关。
虽然在很多 MySQL 运维规范里，都建议单表不超过 500w、1000w。
但实际上，我在生产环境，也见过大小超过 2T，记录数过亿的表，同时，业务不受影响。
单表过大时，业务通常会考虑两种拆分方案：水平切分和垂直切分。
水平拆分 VS 垂直拆分
水平切分，拆分的维度是行，一般会根据某种规则或算法将表中的记录拆分到多张表中。
拆分后的表既可在一个实例，也可在多个不同实例中。如果是后者，又会涉及到分布式事务。
垂直切分，拆分的维度是列，一般是将列拆分到多个业务模块中。这种拆分更多的是上层业务的拆分。
从改造的复杂程度来说，前者小于后者。
所以，在单表数据量过大时，业界用得较多的还是水平拆分。
常见的水平拆分方案有：分库分表、分区表。
虽然分库分表是一个比较彻底的水平拆分方案，但一方面，它的改造需要一定的时间；另一方面，它对开发的能力也有一定的要求。相对来说，分区表就比较简单，也无需业务改造。
分区表
很多人可能会认为 MySQL 的优势在于 OLTP 应用，对于 OLAP 应用就不太适合，所以，也不太推荐分区表这种偏 OLAP 的特性。
但实际上，对于某些业务类型，还是比较适合使用分区表的，尤其是那些有明显冷热数据之分，且数据的冷热与时间相关的业务。
下面，我们看看分区表的优点：
提升查询性能
对于分区表的查询操作，如果查询条件中包含分区键，则这个查询操作就只会被下推到符合条件的分区内进行，无关分区将自动过滤掉。
在数据量比较大的情况下，能提升查询速度。
对业务透明
将表从一个非分区表转换为分区表，业务端无需做任何改造。
管理方便
在对单个分区进行删除、迁移和维护时，不会影响到其它分区。
尤其是针对单个分区的删除（DROP）操作，避免了针对这个分区所有记录的 DELETE 操作。
遗憾的是，MySQL 分区表不支持并行查询。理论上，当一个查询涉及到多个分区时，分区与分区之间应进行并行查询，这样才能充分利用多核 CPU 资源。
但 MySQL 并不支持，包括早期的官方文档，也提到了这个问题，也将这个功能的实现放到了优先级列表中。
These features are not currently implemented in MySQL Partitioning, but are high on our list of priorities.
- Queries involving aggregate functions such as SUM() and COUNT() can easily be parallelized. A simple example of such a query might be SELECT salesperson_id, COUNT(orders) as order_total FROM sales GROUP BY salesperson_id;. By “parallelized,” we mean that the query can be run simultaneously on each partition, and the final result obtained merely by summing the results obtained for all partitions.
- Achieving greater query throughput in virtue of spreading data seeks over multiple disks.
来源：https://www.cnblogs.com/ivictor/p/15713667.html
图文来源于网络，如有侵权请联系删除。