MYSQL有分区表，分区表同样能达到IO分散、提高性能的目的，而且更简单，更方便，为何还要采用分库分表呢。
我想主要有以下几个方便的原因：
1、MYSQL 对多CPU的支持还不是很好，还不能充分发挥多CPU的能力，如不支持并行，很多东西都不支持在线DDL等，
如果将分表数据堆积成分区表，即便IO不是问题，MYSQL自身管理上也是个问题，效率比分表差太多。
2、MYSQL分区表自身的不完善，坑太多，有时完全起不到分区表的作用，和巨大单表无二致，甚至更差。
3、分区表，分区键设计不太灵活，如果不走分区键，很容易出现全表锁，性能大幅下降。
4、自己分库分表，自己掌控业务场景与访问模式，可控。分区表，研发写了一个sql，都不确定mysql是怎么玩的，不太可控。
5、备份恢复问题，巨大的单表导致备份恢复时间成倍增加，加大整库备份恢复失败风险，在一些业务场景下，
甚至不能在有限的时间窗口内完成备份。
6、管理维护问题，如DDL，表一大简直是一场灾难。
所以，现在很多的互联网公司的一些互联网应用，很少有采用分区表的，而大都采用分库分表。
随着业务的不断发展，数据库中的数据会越来越多，相应地，单表的数据量也会越到越大，大到一个临界值，单表的查询性能就会下降。
这个临界值，并不能一概而论，它与硬件能力、具体业务有关。
虽然在很多 MySQL 运维规范里，都建议单表不超过 500w、1000w。
但实际上，我在生产环境，也见过大小超过 2T，记录数过亿的表，同时，业务不受影响。
单表过大时，业务通常会考虑两种拆分方案：水平切分和垂直切分。
水平切分，拆分的维度是行，一般会根据某种规则或算法将表中的记录拆分到多张表中。
拆分后的表既可在一个实例，也可在多个不同实例中。如果是后者，又会涉及到分布式事务。
垂直切分，拆分的维度是列，一般是将列拆分到多个业务模块中。这种拆分更多的是上层业务的拆分。
从改造的复杂程度来说，前者小于后者。
所以，在单表数据量过大时，业界用得较多的还是水平拆分。
常见的水平拆分方案有：分库分表、分区表。
虽然分库分表是一个比较彻底的水平拆分方案，但一方面，它的改造需要一定的时间；另一方面，它对开发的能力也有一定的要求。相对来说，分区表就比较简单，也无需业务改造。
很多人可能会认为 MySQL 的优势在于 OLTP 应用，对于 OLAP 应用就不太适合，所以，也不太推荐分区表这种偏 OLAP 的特性。
但实际上，对于某些业务类型，还是比较适合使用分区表的，尤其是那些有明显冷热数据之分，且数据的冷热与时间相关的业务。
下面，我们看看分区表的优点：
遗憾的是，MySQL 分区表不支持并行查询。理论上，当一个查询涉及到多个分区时，分区与分区之间应进行并行查询，这样才能充分利用多核 CPU 资源。
但 MySQL 并不支持，包括早期的官方文档，也提到了这个问题，也将这个功能的实现放到了优先级列表中。
在 MySQL 5.7 中，对于分区表，有个很重大的更新，即 InnoDB 存储引擎原生支持了分区，无需再通过 ha_partition 接口来实现。
所以，在 MySQL 5.7 中，如果要创建基于 MyISAM 存储引擎的分区表，会提示 warning 。
而在 MySQL 8.0 中，则更为彻底，server 层移除了 ha_partition 接口代码。
如果要使用分区表，只能使用支持原生分区的存储引擎。在 MySQL 8.0 中，就只有 InnoDB。
这就意味着，在 MySQL 8.0 中，如果要创建 MyISAM 分区表，基本上就不可能了。
这也从另外一个角度说明了为什么生产上不建议使用 MyISAM 表。
在使用分区表时，大家常常会碰到下面这个报错。
即分区键必须是主键的一部分。
上面的 opr 是一张 *** 作流水表。其中，opr_no 是 *** 作流水号，一般都会被设置为主键，opr_date 是 *** 作时间。基于 *** 作时间来进行分区，是一个常见的分区场景。
为了突破这个限制，可将 opr_date 作为主键的一部分。
但是这么创建，又会带来一个新的问题，即对于同一个 opr_no ，可插入到不同分区中。如下所示：
这实际上违背了业务对于 opr_no 的唯一性要求。
既然这样，有的童鞋会建议给 opr_no 添加个唯一索引，But，现实是残酷的。
即便是添加唯一索引，分区键也必须包含在唯一索引中。
总而言之，对于 MySQL 分区表，无法从数据库层面保证非分区列在表级别的唯一性，只能确保其在分区内的唯一性。
这也是 MySQL 分区表所为人诟病的地方之一。
但实际上，这个锅让 MySQL 背并不合适，对于 Oracle 索引组织表（ InnoDB 即是索引组织表），同样也有这个限制。
Oracle 官方文档（ http://docs.oracle.com/cd/E11882_01/server.112/e40540/schemaob.htm#CNCPT1514），在谈到索引组织表（Index-Organized Table，简称 IOT）的特性时，就明确提到了 “分区键必须是主键的一部分”。
下面，我们看看刚开始的建表 SQL ，在 Oracle 中的执行效果。
同样报错。
注意，这里指定了 ORGANIZATION INDEX ，创建的是索引组织表。
看来，分区键必须是主键的一部分并不是 MySQL 的限制，而是索引组织表的限制。
之所以对索引组织表有这样的限制，个人认为，还是基于性能考虑。
假设分区键和主键是两个不同的列，在进行插入 *** 作时，虽然也指定了分区键，但还是需要扫描所有分区才能判断插入的主键值是否违反了唯一性约束。这样的话，效率会比较低下，违背了分区表的初衷。
而对于堆表则没有这样的限制。
在堆表中，主键和表中的数据是分开存储的，在判断插入的主键值是否违反唯一性约束时，只需利用到主键索引。
但与 MySQL 不一样的是，Oracle 实现了全局索引，所以针对上面的，同一个 opr_no，允许插入到不同分区中的问题，可通过全局唯一索引来规避。
但 MySQL 却无能为力，之所以会这样，是因为 MySQL 分区表只实现了本地分区索引（Local Partitioned Index），而没有实现 Oracle 中的全局索引（Global Index）。
本地分区索引和全局索引的原理图如下所示：
结合原理图，我们来看看两种索引之间的区别：
1. MySQL 分区表关于“分区键必须是唯一键（主键和唯一索引）的一部分”的限制，本质上是索引组织表的限制。
2. MySQL 分区表只实现了本地分区索引，没有实现全局索引，所以无法保证非分区列的全局唯一。
如果要保证非分区列的全局唯一，只能依赖业务实现了。
3. 不推荐使用 MyISAM 分区表。当然，任何场景都不推荐使用 MyISAM 表。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）