这问题其实涉及到InnoDB存储引擎对可变长度字段的核心处理逻辑，我给你逐个拆解清楚：

为什么增大VARCHAR长度返回“0 row(s) affected”？ #

首先要明确：0 row(s) affected不代表命令没生效，而是没有任何行的实际存储数据被修改。

VARCHAR类型的存储分两部分：

• 表的元数据（记录该字段的最大长度限制）
• 行的实际数据（每个值的长度标记+真实字符内容）

当你执行ALTER TABLE profile CHANGE COLUMN username username VARCHAR(100) DEFAULT NULL;时：

• 你只是放宽了字段的最大长度限制，从允许最多50个latin1字符（单字节，对应50字节）改成100个。
• 现有表中所有username的实际数据都没超过原50字符的限制，所以不需要修改任何行的实际存储内容，只需要更新表的元数据信息。
• MySQL统计“受影响行数”的依据是是否修改了行的实际数据，所以返回0行受影响，但表结构已经成功更新（你可以用DESCRIBE mytable;验证username的长度已经变成100）。

为什么增大长度的ALTER命令执行速度极快？ #

这是因为InnoDB对这类DDL操作做了针对性优化，属于**在线DDL（Online DDL）**里的“仅修改元数据”类型：

• 当修改VARCHAR字段长度为变长时，只要新长度没超过当前行格式的前缀存储限制（比如COMPACT/DYNAMIC格式下，VARCHAR长度不超过768字节时，前缀都存在行内），InnoDB只需要修改表的元数据文件（比如ibd文件的头部信息），不需要重建整个表，也不需要遍历任何行数据。
• 不管你的表有1万行还是100万行，这类操作的耗时几乎可以忽略不计，本质只是修改几个字节的元数据。

为什么缩小长度时会显示“9209 row(s) affected”？ #

当你把VARCHAR(100)改回VARCHAR(50)时，逻辑完全不同：

• MySQL必须遍历表中所有行，检查每一行的username字段是否超过新的50字符限制（如果有数据超过会直接报错终止操作）。
• 即使所有数据都符合限制，这个扫描和验证的过程也会被统计为“影响行数”，所以返回9209行受影响。
• 这类操作需要遍历全表，甚至可能需要重建表结构，所以执行速度会比增大长度慢很多。

验证表结构更新的方法 #

你可以执行以下命令确认修改已经生效：

-- 查看表字段结构
DESCRIBE mytable;

-- 查看完整表创建语句
SHOW CREATE TABLE mytable;

会看到username字段已经是VARCHAR(100)了。

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