直接改row_format=dynamic是最稳妥的解法，它使长字段仅存20字节指针于主记录页，彻底规避8126字节内联瓶颈；而innodb_strict_mode=0仅掩盖问题，不改变compact格式下768字节前缀仍内联的本质。
直接改 ROW_FORMAT=DYNAMIC 是最稳妥的解法，不是临时 workaround，而是治本——它让长字段（VARCHAR、TEXT）真正“移出”主记录页，只留 20 字节指针，彻底绕开 8126 字节的内联存储瓶颈。
为什么 innodb_strict_mode=0 不是正解
关掉严格模式（SET innodb_strict_mode = OFF 或配置文件设 innodb_strict_mode=0）只是让 MySQL 忽略行大小校验，强行建表。但问题没消失：
- 表仍用
COMPACT行格式，所有VARCHAR字段前 768 字节仍硬塞进主记录页 - 后续插入实际数据时，一旦某行真实长度超限，照样报错或静默截断
- MySQL 8.0+ 默认开启严格模式，关它等于放弃一致性保障
确认当前表是否卡在 COMPACT 格式
别猜，查清楚再动手：
- 运行
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，结果中ROW_FORMAT显示为Compact就确认了
安全切换到 DYNAMIC 的操作要点
DYNAMIC 能生效，依赖两个前提，缺一不可：
-
innodb_file_per_table必须为ON（MySQL 5.6.6+ 默认开启；若为OFF，ALTER TABLE ... ROW_FORMAT=DYNAMIC会被静默降级回COMPACT） - 执行前先备份，虽然 5.6+ 支持 online DDL，但大表
ALTER仍可能锁表较久 - 正确顺序：
SET SESSION innodb_file_per_table = ON;→ALTER TABLE your_table ROW_FORMAT = DYNAMIC; - 完成后跑一次
ANALYZE TABLE your_table;，更新统计信息，避免优化器误判行大小导致执行计划退化
哪些字段该优先改成 TEXT 或 BLOB
不是所有长字段都必须改，重点盯这些：
- 定义为
VARCHAR(5000)且实际内容经常接近上限的字段（utf8mb4下单字符最多占 4 字节，5000×4 = 20000 字节，远超内联阈值） - 多个
VARCHAR字段加起来理论最大长度已逼近 65535（含行头、空值位图等开销） - 字段语义本身就是长文本（如日志、脚本、HTML 片段），哪怕当前内容短，也应提前用
TEXT预留弹性 - 避免把
VARCHAR(10000)改成VARCHAR(10800)—— 这会让理论占用从 ≈43200 字节涨到 ≈43200+，反而更易触发 65535 总上限
真正容易被忽略的是：DYNAMIC 行格式下，TEXT 和 BLOB 的前 768 字节不再内联存储，整个值都放在溢出页；而 COMPACT 下它们仍会存前缀。所以改格式 + 改类型要一起做，单改其一效果有限。
