结论是：MySQL 1118错误根本原因并非数据内容过大，而是InnoDB在页内组装行记录时，因头信息、NULL位图、字段长度标识及utf8mb4字符膨胀等叠加导致超8126字节硬限制；最准确高效的解法是改用ROW_FORMAT=DYNAMIC，并确保innodb_file_per_table=ON，而非通过关闭innodb_strict_mode来掩盖问题。
直接说结论：这不是你数据“太大”，而是InnoDB在页内组装一行记录时，头信息、NULL位图、字段长度标识、utf8mb4字符膨胀等叠加后超了8126字节硬限制——改ROW_FORMAT=DYNAMIC是最准、最省事的解法，别碰innodb_strict_mode=0来掩盖问题。
怎么确认表正卡在COMPACT行格式上
错误提示里如果出现In current row format, BLOB prefix of 768 bytes is stored inline，基本就坐实了。执行这两条命令验证：
-
SHOW CREATE TABLE your_table;—— 看输出里有没有ROW_FORMAT=COMPACT，或者压根没写（MySQL 5.7 及以前默认就是 COMPACT） -
SELECT NAME, ROW_FORMAT FROM information_schema.INNODB_SYS_TABLES WHERE NAME = 'your_db/your_table';—— 注意格式是db_name/table_name，返回Compact即确认
ALTER TABLE切DYNAMIC前必须检查的三件事
ROW_FORMAT=DYNAMIC不是一改就灵，它依赖底层文件组织方式：
-
innodb_file_per_table必须为ON（MySQL 5.6.6+ 默认开启；若为OFF，DYNAMIC会被静默降级回COMPACT） - MySQL 5.7.7+ 和 8.0+ 已移除
innodb_file_format参数，不用设BARRACUDA，设了也无效 - 大表执行
ALTER TABLE your_table ROW_FORMAT = DYNAMIC;可能锁表较久，建议低峰期操作，且先备份
导入SQL文件时报错，怎么批量修而不是一张张改
如果你是导入一个.sql备份文件（比如20260615.sql）时崩了，别手动ALTER每张表：
- 用文本编辑器打开SQL文件，全局搜索
ENGINE=InnoDB，替换成ENGINE=InnoDB ROW_FORMAT=DYNAMIC - 如果建表语句里已有
ROW_FORMAT=COMPACT或ROW_FORMAT=REDUNDANT，直接替换成ROW_FORMAT=DYNAMIC - 确保文件头部没有
SET SESSION innodb_strict_mode = 0;这类掩耳盗铃的语句——它只会让后续查询出NULL值，不解决根本问题
真正容易被忽略的是：改完ROW_FORMAT后，记得跑一次ANALYZE TABLE your_table;。否则优化器可能还按旧的行大小估算执行计划，导致慢查询复现。
