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.

 

源码分析

从前一篇文章中我们知道MySQL在compare_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个字节来保存实际长度，就没这个问题了。下篇再续。

 

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