能绕过报错但不治本，因innodb_strict_mode=OFF仅放宽建表校验，实际写入仍可能失败；MySQL 5.7+/8.0中部分版本忽略该设置，且失去结构合理性保护，推荐改用ROW_FORMAT=DYNAMIC或优化字段设计。
直接关掉 innodb_strict_mode 能绕过报错，但不解决根本问题，且在 mysql 5.7+ 和 8.0 中可能无效甚至引发其他隐患。
为什么改 innodb_strict_mode=OFF 有时“管用”？
这个参数控制 InnoDB 是否严格执行行大小、索引长度等限制。设为 OFF 后，MySQL 会容忍部分超限的建表语句（比如含大量 VARCHAR(1000) 字段的表），允许创建成功，但实际写入数据时仍可能失败或行为异常。
常见误操作场景：
- 在 Navicat 导入 SQL 文件前，临时执行
SET GLOBAL innodb_strict_mode = OFF;—— 仅对当前会话生效，Navicat 批量导入通常新建多个连接，该设置不生效 - 修改
my.ini或my.cnf的[mysqld]段落，添加innodb_strict_mode=0并重启 MySQL —— 这确实能全局绕过校验，但代价是失去对表结构合理性的保护 - MySQL 8.0.13+ 默认强制开启 strict mode，且部分版本已忽略配置文件中的关闭指令，此时硬关会失败
ROW_FORMAT=DYNAMIC 是更稳妥的替代方案
报错信息里明确提示：Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help。这是因为 DYNAMIC 行格式允许 TEXT/BLOB 类型的前缀（默认 768 字节）存于行内，其余内容存于溢出页，从而大幅降低行内占用。
实操建议：
- 在建表语句末尾显式加上
ROW_FORMAT=DYNAMIC，例如：CREATE TABLE example ( id INT PRIMARY KEY, content TEXT ) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;
- 若 SQL 文件已生成，可用文本编辑器全局替换：
ROW_FORMAT=COMPACT→ROW_FORMAT=DYNAMIC（注意保留空格和分号） - 对已有表修复：
ALTER TABLE your_table ROW_FORMAT=DYNAMIC;，但需确保innodb_file_per_table=ON（MySQL 5.6.6+ 默认开启）
真正该动的是字段定义，不是配置开关
报错本质是设计问题：一行里堆了太多宽 VARCHAR 字段，尤其用了 utf8mb4 字符集后，每个字符占 4 字节。例如 VARCHAR(2000) + VARCHAR(3000) + VARCHAR(1500) 就已达 (2000+3000+1500)×4 = 26000 字节，远超 8126 这个触发阈值（注意：8126 是 InnoDB 页面内行头 + 内联数据的软限制，非绝对上限）。
优先检查并调整：
- 把非必需的长文本字段（如日志、备注、HTML 片段）从
VARCHAR(8000)改为TEXT——TEXT不计入行内尺寸计算 - 确认是否真需要
VARCHAR(255)存用户名；多数场景VARCHAR(64)或VARCHAR(128)更合理 - 避免在同一个表里塞 10+ 个
VARCHAR(500)字段；考虑按业务拆分到关联表
最易被忽略的一点：Navicat 导入时默认使用「快速执行」模式，它会跳过部分语法校验直接发包，反而让 innodb_strict_mode 失效逻辑更不可控。遇到反复报错，先在命令行用 mysql -u root -p < dump.sql 测试，错误信息更准确，也更容易定位是哪条 CREATE TABLE 语句越界。
