InnoDB表快速修改varchar字段长度方案

前一篇文章末尾提到InnoDB快速修改字段长度。其实用场景在于,在设计表时,若需要预留varchar类型字段,还无法确定实际需要的长度。而当需要启用到预留的字段时,表中可能已经有很多数据,此时要根据需要修改字段长度, 若能够不需要重做数据,则能够减少这个修改操作对线上服务的影响。

几点说明

1、 注意到这里适用的是varchar类型, char类型不在本文讨论范围内。实际上,由于varchar类型字段数据并不是直接存储在聚簇索引中,才使得快速修改成为可能。而char类型改变长度至少要将整个聚簇索引重做,因此不能做到“不修改数据”

2、 与前一篇文章的思路类似,我们的目的是在执行alter table语句的时候,只修改frm文件。

3、 当然实际执行alter table修改字段长度的时候,考虑到字段中可能已经有数据,因此若是长度定义变小,则必须重做数据,因为超过长度的数据要作截断,否则逻辑上就不通过了。 因此这里只适用于将长度改大的情况。 从我们的需求出发点来看,这一点问题并不大,在预留的时候设置“小一些”即可。(小是相对的,后面会说到)

4、 我们用到的语句形如 alter table t c c varchar(300) default null. c字段原来声明为varchar(290) default null.

源码分析

从前一篇文章中我们知道MySQLcompare_tables这个函数中判断当前执行的alter table语句是否需要重做数据。

在这个函数中有这么一段

/*

Go through fields and check if the original ones are compatible

with new table.

*/

for()

{

if (!(tmp= field->is_equal(tmp_new_field)))

{

*need_copy_table= ALTER_TABLE_DATA_CHANGED;

DBUG_RETURN(0);

}

}

for循环中对每个字段的修改作了判断,其中field->is_equal就用于判断修改前后的字段定义是否完全相同。这里field是一个基类对象,通过多态调用Field_varstring::is_equal (sql/field.cc).

uint Field_varstring::is_equal(Create_field *new_field)

{

if (new_field->sql_type == real_type() &&

new_field->charset == field_charset)

{

if (new_field->length == max_display_length())

return IS_EQUAL_YES;

if (new_field->length > max_display_length() &&

((new_field->length <= 255 && max_display_length() <= 255) ||

(new_field->length > 255 && max_display_length() > 255)))

return IS_EQUAL_PACK_LENGTH; // VARCHAR, longer variable length

}return IS_EQUAL_NO;

}

这个函数的逻辑比较简单。 real_type()返回的是当前的字段类型(当然是varcahr), field_charset是当前字段实用的字符集, max_display_length()返回当前定义的长度。

我们看到这个函数有三种返回值, 其中IS_EQUAL_PACK_LENGTH类似我们需要的情况,为什么说类似呢, 这个判断中要求的不仅仅是长度增大,还要求修改前后的长度定义,要么都小于255,要么都大于255 这个深层原因给我们带来一点麻烦,后面再说。

IS_EQUAL_PACK_LENGTH这个返回值,说明框架层考虑到这种情况是可以特殊处理的,而遗憾的是InnoDB源码中没有利用这个值,我们就用这个返回值来修改一下InnoDB中的判断逻辑。

简单修改

为了不影响其他引擎的结果,我们只在InnoDB内部修改。我们知道check_if_incompatible_data这个函数的返回值,决定了MySQL是否重做表数据。

bool

ha_innobase::check_if_incompatible_data(

HA_CREATE_INFO* info,

uint table_changes)

{

if (table_changes != IS_EQUAL_YES) {

return(COMPATIBLE_DATA_NO);

}

}

这个传入的table_changes, 是前面各种判断的异或结果(因此在我们的例句中,这里的值是IS_EQUAL_YES|IS_EQUAL_PACK_LENGTH)

这里判断逻辑要求必须是 IS_EQUAL_YES. 按照我们的分析,修改成如下

bool

ha_innobase::check_if_incompatible_data(

HA_CREATE_INFO* info,

uint table_changes)

{

if ((table_changes == IS_EQUAL_NO) ||

(table_changes & ~(IS_EQUAL_YES|IS_EQUAL_PACK_LENGTH) != 0)) return(COMPATIBLE_DATA_NO);

}

}

说明:虽然目前只有三种返回值,但从逻辑严谨出发,还是要判断table_changes是否在(IS_EQUAL_YES|IS_EQUAL_PACK_LENGTH)所表示的位标识范围内。

重新编译发布后,执行结果如下。

mysql> alter table t c c varchar(300) default null;

Query OK, 0 rows affected (0.01 sec)

Records: 0 Duplicates: 0 Warnings: 0

可以看到,这回执行基本不需要时间。

遗留问题

细心读者一定发现我们的例子故意绕过了上面说到的255的问题,实际上如果原来定义为varchar(4) 再修改为varchar(300),按照我们的实现,还是需要重做数据的。

判断逻辑可以很简单的修改,问题是,MySQL为什么要作这个255的分界判断?

实际上,varchar字段的实际内容前有1个或2个字节表示实际内容的长度,而到底是1个字节还是2个字节,就取决于创建表或修改的时候,这个字段声明的长度。也就是说,varchar(4) 字段的实际内容前,用1个字节表示实际长度,而varchar(300)的实际内容前,用2个字节。

因此,如果只是在修改前后长度在255两侧,则必须重做数据。

这样造成的问题是,从我们的需求出发,要预留字段时候,就必须先估计预留的字段大概的长度(是否超过255)。

可以将所有的varcahr字段都预留超过255字节,问题并不大,只是增加了1个字节空间而已。

遗留问题的解决方案

当然这事儿也不是不能解决的,InnoDB是为了节省空间,如果我们放弃这个节省策略,对于所有的varchar,都用2个字节来保存实际长度,就没这个问题了。下篇再续。

再次呼唤,本文所作修改目前只作了简单的回归测试。还没有完全确认是否引入副作用,若有相关文章涉及与此相关,请回复或站内私信我。

上一篇:无法从普通用户切换到超级用户的问题


下一篇:一个想法:成立草根技术联盟对开发人员进行技术定级解决企业员工招聘难问题!