为何MySQL 5.7中VARCHAR扩至≥256字节无法用In-place+RebuildTable？

核心原因在于InnoDB行存储结构中长度标识的变化会导致全行字段偏移混乱，和添加列的场景有着本质区别：

• VARCHAR长度标识的存储差异：
  当VARCHAR长度小于256字节时，InnoDB用1个字节存储该字段的实际长度；一旦扩到256字节及以上，长度标识会变成2个字节。这个变化不是在行尾新增内容，而是修改了原有行结构中该字段的前缀部分，导致该行中这个字段之后的所有其他字段的存储偏移量全部发生改变。

• In-place+RebuildTable的适配限制：
  InnoDB的In-place Rebuild（比如添加列时用的方式）之所以能支持DML，是因为原有行的字段偏移没有变化——新增列是追加在行结构末尾，旧数据的读写可以和新结构兼容，DML操作的日志能正常同步到重建后的表中。但VARCHAR长度跨256字节的场景下，旧行数据的字段偏移和新结构完全不匹配，InnoDB无法在原表空间内完成这种逐行的结构转换，也没法在转换过程中正常处理并发DML（因为读写的字段位置已经乱了）。

• ALGORITHM=COPY的必要性：
  COPY方式会全量复制每一行数据，在复制过程中直接将原行的1字节长度标识转换为2字节，生成完全符合新结构的行数据写入新表空间。这种方式虽然锁表时间更长（5.7中COPY是锁表的），但能保证数据结构的一致性，因为它是彻底重建每一行。

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