当前位置 博文首页 > JavaEdge全是干货的技术号：为什么阿里不推荐使用MySQL分区表？
分区表有什么问题，为什么公司规范不让使用分区表呢？
在示例表插入两条记录，按分区规则，记录分别落在p_2018和p_2019分区。
可见，该表包含了一个.frm文件和4个.ibd文件，每个分区对应一个.ibd文件：
举个在分区表加间隙锁的例子，目的是说明对于InnoDB来说，这是4个表。
| session_1 | session_2 | |
|---|---|---|
| T1 | begin; select * from tt where ftime=‘2017-5-1’ for update; | |
| T2 | insert into tt values (‘2018-2-1’, 1); (Query OK) insert into tt values (‘2017-12-1’, 1); (阻塞) |
初始化表tt时，只插入两行数据。session1的select语句对索引ftime上这两个记录之间的间隙加了锁。如果是一个普通表的话，T1时刻，在表t的ftime索引上，间隙和加锁状态应该如下
即‘2017-4-1’ 和’2018-4-1’ 这两个记录之间的间隙会被锁住。
那sesion2的两条插入语句应该都要进入锁等待状态。
但session2的第一个insert成功。因为对于引擎，p_2018和p_2019是两个不同表，即2017-4-1的下一个记录并不是2018-4-1，而是p_2018分区的supremum。
所以T1，在表t的ftime索引上，间隙和加锁的状态其实：
由于分区表规则，session1的select只操作了分区p_2018，因此加锁范围就是上图绿色。
所以，session2写2018-2-1成功，而要写2017-12-1，就要等session1的间隙锁。
这时show engine innodb status的部分结果：
# 把表tt改成MyISAM表
alter table t engine=myisam
对于MyISAM引擎来说，这是4个表。
| session_1 | session_2 |
|---|---|
| alter table t engine=myisam; update tt set c=sleep(100) where ftime=‘2017-4-1’; | |
| select * from tt where ftime=‘2018-4-1’; (Query OK) select * from tt where ftime=‘2017-5-1’; (阻塞) |
在session1，sleep(100)将该语句的执行时间设为100s。由于MyISAM引擎只支持表锁，所以这条update语句会锁住整个表tt上的读。
但session2的第一条查询语句可以正常执行，第二条语句才进入锁等待。
因为MyISAM的表锁实现在引擎层，session1加的表锁，其实是锁在分区p_2018。因此，只会堵住在这个分区上执行的查询，其他分区查询不受影响。
分区表使用起来看来挺好使的呀，为啥禁用？
使用分区表的一个重要原因就是单表过大。那若不使用分区表，就要手动分表。
比如，按年份划分，分别创建普通表t_2017、t_2018、t_2019等。手工分表也要找到需要更新的所有分表，然后依次执行更新。
性能上和分区表没有差别。
所以从引擎层看，也没啥区别。
两种方式的区别，主要在server层。server层的分区表一个严重问题就是打开表的行为。
第一次访问一个分区表时，MySQL需要把所有分区都访问一遍。
一个典型的报错场景：若一个分区表的分区很多，比如超过1000，而MySQL启动时，open_files_limit参数默认值1024，则在访问该表时，由于需要打开所有文件，导致打开表文件的个数超过了上限而报错。
比如对一个包含很多分区的表，执行insert直接报错：
这条insert其实只需要访问一个分区，但语句报错了。这个表是MyISAM，如果使用InnoDB，不会出现该问题。
MyISAM分区表使用通用分区策略（generic partitioning），每次访问分区都由server层控制。通用分区策略，是MySQL一开始支持分区表的时候就存在的代码，在文件管理、表管理的实现上很粗糙，性能问题很严重。
MySQL 5.7.9开始，InnoDB引入本地分区策略（native partitioning），在InnoDB内部自己管理打开分区的行为。
MySQL 5.7.17开始，将MyISAM分区表标记为deprecated。
MySQL 8.0开始，已经禁止创建MyISAM分区表，只允许创建已经实现了本地分区策略的引擎。
目前只有InnoDB和NDB引擎支持本地分区策略。
对于server层，一个分区表就只是一个表。
如图，分别是该例的操作序列和执行结果图。
| session_1 | session_2 |
|---|---|
| begin; select * from tt where ftime=‘2018-4-1’; | |
| alter table tt truncate partition p_2017 (阻塞) |
所以分区表在做DDL时，影响会更大。若使用的普通分表，则当你在truncate一个分表时，肯定不会跟另外一个分表上的查询语句，出现MDL锁冲突。
在server层，认为这是同一张表，因此所有分区共用同一MDL锁
在引擎层，认为这是不同表，因此MDL锁之后的执行过程，会根据分区表规则，只访问必要的分区。
什么是必要的分区？
根据SQL语句中的where条件，结合分区规则。比如上面的where ftime=‘2018-4-1’，根据分区规则year函数算出来的值是2018，那么就会落在p_2019分区。
但若这个where 条件改成 where ftime>='2018-4-1'，虽然查询结果相同，但这时根据where条件，就要访问p_2019和p_others俩分区。
若查询语句的where条件没有分区key，就只能访问所有分区了。当然，这并非分区表的问题。即使是使用业务分表，where条件中没有使用分表的key，也必须访问所有的分表。
一大优势是对业务透明，相对于用户分表来说，使用分区表的业务代码更简洁。还有，分区表可以很方便的清理历史数据。
如果一项业务跑的时间足够长，往往就会有根据时间删除历史数据的需求。这时按时间分区的分区表，就可直接通过alter table t drop partition …这个语法删掉分区，从而删掉过期的历史数据。
alter table t drop partition …是直接删除分区文件，跟drop普通表类似。与delete相比，优势是速度快、对系统影响小。
需要注意的是，我是以范围分区（range）为例和你介绍的。实际上，MySQL还支持hash分区、list分区等分区方法。
实际使用时，分区表跟用户分表，有两个问题：
因此，如果要使用分区表，就不要创建太多分区。我见过一个用户做了按天分区策略，然后预先创建了10年的分区。这种情况下，访问分区表的性能自然是不好的。这里有两个问题：
分区表的其他问题，比如查询需要跨多个分区取数据，查询性能就会比较慢，基本上就不是分区表本身的问题，而是数据量或说使用方式问题。
如果你的团队已经维护了成熟的分库分表中间件，用业务分表，对业务开发同学没有额外的复杂性，对DBA也更直观，自然更好。
