优先改ROW_FORMAT=DYNAMIC并显式将长文本字段设为TEXT/BLOB；因DYNAMIC将≥768字节字段整体移出主记录页、仅留20字节指针，避免超8126字节限制，而innodb_strict_mode=0仅掩盖问题。
直接改 ROW_FORMAT=DYNAMIC 是最有效、最安全的解法，但必须配合 innodb_file_per_table=ON，且不能依赖 innodb_strict_mode=0 来绕过。
确认当前表是否卡在 COMPACT 行格式
错误提示里明确说 “In current row format, BLOB prefix of 768 bytes is stored inline”，说明你正用着 COMPACT（或 REDUNDANT）——这两种格式会把每个 VARCHAR、TEXT 的前 768 字节硬塞进主记录页，极易触达 8126 字节上限。
执行：
SHOW CREATE TABLE your_table;
看输出里有没有 ROW_FORMAT=COMPACT 或压根没声明（MySQL 5.7 及之前默认就是 COMPACT）。
也可以查系统表：
SELECT NAME, ROW_FORMAT FROM information_schema.INNODB_SYS_TABLES WHERE NAME LIKE 'your_db/your_table';
注意表名是 db_name/table_name 格式，且结果中 ROW_FORMAT 显示为 Compact（首字母大写）即确认。
ALTER TABLE 切换到 DYNAMIC 的前提和操作
DYNAMIC 能起效，不是光靠 ALTER 命令就行，它依赖底层文件组织方式：
-
innodb_file_per_table必须为ON（MySQL 5.6.6+ 默认开启；若为OFF，DYNAMIC会被静默降级为COMPACT） - MySQL 5.7.7+ 和 8.0+ 不再需要设
innodb_file_format=Barracuda，该参数已被移除 - 执行前建议先备份，虽然
ALTER TABLE ... ROW_FORMAT=DYNAMIC在 5.6+ 支持 online DDL，但大表仍可能锁表较久
正确操作顺序：
SET SESSION innodb_file_per_table = ON;<br>ALTER TABLE your_table ROW_FORMAT = DYNAMIC;
完成后运行：
ANALYZE TABLE your_table;
更新统计信息，避免优化器误判行大小导致执行计划退化。
哪些 VARCHAR 字段该转成 TEXT/BLOB，而不是硬撑
别只改行格式就完事。如果表里有多个长 VARCHAR（比如 VARCHAR(4000) 存日志、HTML、JSON），即使开了 DYNAMIC，它们仍可能因内容短而被内联存储，凑一起还是超限。
判断标准：
– 单个字段预期长度经常 > 1000 字节
– 多个同类字段（≥ 2–3 个）同时存在
– 字段内容不参与 WHERE 或 ORDER BY 等高频索引操作
这时应显式改成：
ALTER TABLE your_table MODIFY COLUMN log_content TEXT;
或 MEDIUMTEXT。注意：TEXT 类型本身不占行内空间（只留 20 字节指针），且 MySQL 8.0+ 对 TEXT 索引长度限制已放宽，不必担心功能阉割。
为什么别碰 innodb_strict_mode=0
关掉严格模式会让 MySQL 允许创建“逻辑上超限”的表，但只是掩盖问题：
– 后续插入稍长一点的数据仍会失败
– 表结构实际不可靠，迁移或升级时大概率暴雷
– EXPLAIN 显示的行大小估计严重失真，影响查询性能
执行 SHOW VARIABLES LIKE 'innodb_strict_mode'; 如果返回 ON，说明系统在帮你守住底线——这不是 bug，是 guardrail。
真正容易被忽略的是：哪怕你改了 ROW_FORMAT=DYNAMIC，如果表里还有 VARCHAR(65535) 这种巨无霸字段（哪怕只一个），InnoDB 仍可能因内部长度计算溢出而拒绝建表。这时候必须拆分或转 TEXT，没有捷径。
