需将表行格式改为DYNAMIC并启用innodb_large_prefix，或缩减VARCHAR长度、改用JSON字段、降级字符集；注意5.6版本兼容性及mysqldump还原问题。
MySQL ALTER TABLE 报 Row size too large 怎么办
直接原因是单行总长度超了 innodb 页限制（默认 65,535 字节），不是字段数多，而是所有列定义的“理论最大宽度”加起来爆了。常见于大量 varchar(255) 或 text 混用、又开了 row_format=compact 的老表。
为什么改个字段长度也会触发这个错
InnoDB 计算行大小时，会把每个 VARCHAR 按声明长度上限算（比如 VARCHAR(500) 算作 500 字节 + 2 字节长度头），哪怕实际只存 3 个字符。ALTER 操作重建表时重新校验，一不小心就超限。
-
VARCHAR在utf8mb4下按 4 字节/字符算上限（VARCHAR(255)→ 最多占 255×4+2 = 1022 字节） -
TEXT/BLOB类型只计入 20 字节指针，但实际内容存在溢出页，不影响此报错 - 启用
innodb_large_prefix=ON且ROW_FORMAT=DYNAMIC或COMPRESSED才支持单列 > 768 字节 - MySQL 5.7.7+ 默认开启
innodb_large_prefix，但老表迁移后可能仍保留旧ROW_FORMAT
快速绕过或修复的实操路径
别硬扛，优先选副作用小、见效快的方式：
- 给表显式指定新格式：
ALTER TABLE t1 ROW_FORMAT=DYNAMIC;（必须配合innodb_large_prefix=ON） - 把真正不需要那么长的
VARCHAR改短，比如VARCHAR(255)→VARCHAR(191)（适配 utf8mb4 索引限制，也减体积） - 确认是否真需要
utf8mb4：如果业务不用 emoji/生僻字，降级到utf8（3 字节/字符），能省约 25% 宽度 - 避免在同一个表里堆几十个
VARCHAR(255)—— 合并成 JSON 字段（JSON类型只计 20 字节）或拆表更可持续
容易被忽略的兼容性坑
改 ROW_FORMAT 不是万能解药：
- MySQL 5.6 默认
innodb_large_prefix=OFF，即使设了DYNAMIC，超长列仍被截断为 768 字节，且不报错 —— 查information_schema.INNODB_SYS_COLUMNS才能发现 -
mysqldump导出的建表语句默认不带ROW_FORMAT，还原后变回COMPACT，错误重现 - 从 MySQL 5.7 升级到 8.0 后，
innodb_default_row_format默认是DYNAMIC，但已有表不会自动升级，得手动ALTER -
VARCHAR长度改小是 DDL，会锁全表；如果数据量大，得评估维护窗口
最麻烦的情况其实是：你改的是别人写的 legacy 表，字段语义模糊，不敢随便缩长度，又没权限调全局配置 —— 这时候只能拆字段、归档冷数据，或者接受加字段前先删几个不用的列。
