MySQL 8.x InnoDB扩展varchar(255)到1024为何未用copy算法？

核心原因：InnoDB 8.0.20+的在线DDL优化 #

在MySQL 8.0.20及后续版本，InnoDB针对动态或压缩行格式的表，新增了varchar列长度扩展的优化逻辑：

• 当你将varchar列从≤255扩展到≤1024时，只要表使用动态/压缩行格式，InnoDB无需复制全表数据，仅需修改表的元数据即可完成操作，对应使用INPLACE算法，因此耗时极短（0.07秒）。
• 当你显式指定ALGORITHM=COPY时，MySQL会强制触发全表复制逻辑，所以耗时与全表扫描复制一致（26.54秒）。

为什么缩小长度始终耗时一致？ #

将varchar(1024)缩小到255时，MySQL需要检查每一行数据是否符合新的长度限制（避免数据截断），同时需要调整行存储的结构信息，这类操作无法通过仅修改元数据完成，无论是否显式指定算法，都必须使用COPY算法，因此耗时始终等于全表复制的时间。

关于官方文档描述的歧义 #

你查阅的官方文档内容可能存在前提条件未明确说明：该描述仅适用于静态行格式的表。静态行格式下，varchar(255)会以固定长度存储（填充空格），扩展到1024需要改变行的物理结构，因此必须使用COPY算法；而动态/压缩行格式下，varchar采用可变长度存储，扩展长度时无需修改现有数据，仅更新元数据即可完成。

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