首选方案是执行ALTER TABLE your_table ROW_FORMAT=DYNAMIC，该操作在线生效、不改业务逻辑，可使长字段内容移出主页面仅留20字节指针；若仍有超长VARCHAR（如存日志、JSON），应直接改为TEXT或JSON类型，并删除冗余DEFAULT值。
别关 innodb_strict_mode，它只是让错误晚点爆，不是真解决。
为什么还原时突然报 Row size too large (> 8126)
导入 SQL 文件（尤其是他人导出的）时，表结构里可能含多个大 VARCHAR 字段（比如 VARCHAR(5000)）、或大量短 VARCHAR 字段叠加（如 30+ 个 VARCHAR(255)），在默认 ROW_FORMAT=COMPACT 下，InnoDB 会把它们尽可能塞进主记录页——单行开销轻松突破 8126 字节上限。还原过程本质是执行 CREATE TABLE + INSERT，建表阶段就卡住。
ALTER TABLE ROW_FORMAT=DYNAMIC 是首选操作
这是唯一能在线修复、且不改业务逻辑的方案。前提是 innodb_file_per_table=ON（MySQL 5.6+ 默认开启，可查 SHOW VARIABLES LIKE 'innodb_file_per_table'; 确认）。
- 先确认原表格式：
SHOW CREATE TABLE your_table;—— 若没显式声明ROW_FORMAT，基本就是COMPACT - 执行修改：
ALTER TABLE your_table ROW_FORMAT=DYNAMIC;（MySQL 5.6+ 支持在线 DDL，不影响读写） - 修改后立即生效，但建议补一句：
ANALYZE TABLE your_table;，避免优化器误判统计信息 - 注意：该语句只改表格式，不自动迁移已有数据；后续新插入或更新的行才会按
DYNAMIC规则处理长字段（≥768 字节内容移出主页，仅留 20 字节指针）
哪些字段必须转成 TEXT 或 BLOB
光改 ROW_FORMAT 不够，如果表里还有硬撑的超长 VARCHAR，比如存日志、HTML、JSON 片段，仍可能在某些场景下触发边界问题（例如多字段同时写满）。这类字段应直接改类型：
- 实际平均长度 > 1000 字符，且几乎不用在
WHERE/ORDER BY中过滤或排序 → 改为TEXT - 明确存储 JSON、XML、Base64、富文本 → MySQL 5.7+ 用
JSON类型，否则用LONGTEXT，别用VARCHAR(16383) - 删掉冗余
DEFAULT值，尤其长字符串默认值（如DEFAULT 'default_content_here...'）会加重行头开销 - 执行前务必备份：
CREATE TABLE your_table_bak AS SELECT * FROM your_table;
innodb_strict_mode=0 是危险开关
它会让建表或加字段“成功”，但隐患立刻埋下：
- 后续真实插入数据时仍可能报错（比如一个
VARCHAR(10000)字段实际存了 9500 字符） - 查询性能下降：InnoDB 可能被迫做额外页外读取，甚至行迁移
- 备份工具（如
mysqldump）可能因元数据不一致而失败 - 若真要临时启用，必须用
SET GLOBAL innodb_strict_mode = OFF;（需 SUPER 权限），且重启后失效；配置文件改需重启 MySQL，不推荐
真正难处理的是那些字段语义模糊、又不敢轻易改类型的遗留表——这时候得结合业务判断：到底是砍字段、拆关联表，还是接受一次停机重导。行大小限制背后，其实是表设计是否贴合真实读写模式的镜子。
