MySQL 5.7分区表修改字段数据类型耗时高于非分区表原因咨询

你执行的varchar(45)转varchar(50)属于同类型字段长度向上调整，且调整前后长度均小于255，不需要修改varchar存储前缀的字节占用，在非分区InnoDB表上可以走即时元数据变更，不需要重建表、不需要扫描全量数据，所以不到1秒即可完成。

分区表执行同操作耗时极长的核心原因如下：

• 5.7版本分区表的实现架构缺陷：MySQL 5.7的分区表逻辑是在Server层实现的，没有下沉到InnoDB引擎层，大部分InnoDB提供的in-place DDL优化对分区表不生效。哪怕是仅需修改元数据的轻量DDL，也会触发全部分区的表重建逻辑。
• 分区表DDL的执行逻辑冗余：处理分区表的字段修改操作时，Server层将每个独立分区视为单独的表逐一执行变更，每个分区都要走全量数据拷贝、重建索引的流程，总耗时约等于单表变更耗时乘以分区数量，远高于非分区表的同操作耗时。

你可以执行如下命令验证操作是否需要重建表，如果输出不支持ALGORITHM=INPLACE的报错，即可确认该操作确实会触发表重建：

ALTER TABLE 你的分区表名 MODIFY COLUMN 目标字段名 varchar(50) [其他字段原有属性], ALGORITHM=INPLACE, LOCK=NONE;

如果需要在生产环境执行该变更，建议使用在线DDL工具避免长时间锁表影响业务。

内容的提问来源于stack exchange，提问作者jithin giri