背景

近期接到一个产品需求，由于上游业务字段扩大了字段，下游的字段也得跟着调整扩大，这就涉及几十张大表，十几亿行数据的变更。

如果按照传统方式 onlie-ddl 借用第三方工具也得三四天分批跑，看了看MySQL官网，感觉应该会有更快的方式。

SQL变更

这里原来是 varchar(64)的，需要扩展到 varchar(255)
ALTER TABLE `test`.`tb1`
MODIFY COLUMN `product_name` varchar(255)  NULL DEFAULT NULL COMMENT '商品简称' AFTER `product_code`;

规则：

UTF8MB4的规则下：
规则1：如果 varchar(0-64) 以内的增长是可以秒级扩展的
规则2：如果是从 < 64 的长度扩展到 >64 的长度，则不能秒级扩展
规则3：如果是 >64 的长度扩展到 比原子段更长 的长度，则可以秒级扩展

原理：

如果是从 < 64 的长度扩展到 >64 的长度，则不能秒级扩展，因为改变了数据库的存储结构
由于 VARCHAR 字符类型在字节长度为 1 时可存储的字符为 0~255。当前字符集类型为 UTF8MB4，由于 UTF8MB4 为四字节编码字符集，即一个字节长度可存储 63.75（255/4）个字符，所以当我们将 VARCHAR(63) 修改为 VARCHAR(64) 时，需要增加一个字节去进行数据的存储，就要通过建立临时表的方式去完成本次长度扩容，故需要花费大量时间。

遇到问题

但是总是有些表不按上面的规则来，也就是说 比如从 100 扩展到 255 ，也不是秒级扩展的，这可怎么办，需要先对表做下整理，才能秒级扩展，也就是：
alter table tb1 engine=inondb; 
​
所以定期对大表做整理还是很有必要的。

官网手册：

MySQL ：： MySQL 5.7 参考手册 ：： 11.7 数据类型存储要求