Navicat建表保存报“Row size too large”是因客户端按utf8mb4最大字节估算单行超65535字节而拦截，与服务端无关；唯一可靠解法是设ROW_FORMAT=DYNAMIC并确保innodb_file_per_table=ON。
Navicat建表保存时报错“Row size too large”，不是表数据太大，而是你定义的字段总宽（含字符集膨胀、NULL位图、长度标识）在InnoDB页内组装时超了8126字节硬限制——改ROW_FORMAT=DYNAMIC是唯一可靠解法，其他都是掩耳盗铃。
为什么Navicat设计界面就报错，而SQL直接执行却可能成功？
Navicat 17+ 在点击「保存」前会主动估算行宽：把所有VARCHAR按utf8mb4最大4字节/字符计算，加上隐藏字段、NULL位图、每字段2字节长度标识等，一旦≥65535字节就拦截。这发生在客户端校验层，MySQL服务端根本没收到建表语句。所以哪怕你用命令行能建出来（比如用了ROW_FORMAT=DYNAMIC），Navicat设计界面照样拦。
- 它不看你实际存多少数据，只看“理论最大单行字节数”
- 哪怕你只加一个
VARCHAR(2000)，在utf8mb4下就是8000字节，再加十几个VARCHAR(255)就轻松破8126 - 错误提示里若带
In current row format, BLOB prefix of 768 bytes is stored inline，说明当前是COMPACT格式，已坐实
为什么把VARCHAR改成TEXT就能过Navicat校验？
TEXT和VARCHAR存储机制完全不同：VARCHAR内容全挤在主记录页内，参与65535和8126两层限制；TEXT实际内容存在溢出页，主记录只存20字节指针，完全不计入行宽计算。
- Navicat看到
TEXT类型，立刻跳过该字段的字节估算，右侧“长度”输入框自动变灰 - 但切
TEXT后仍失败？检查：NOT NULL的TEXT必须显式写DEFAULT ''；LONGTEXT不能设字符串默认值；整个表字符集必须统一为utf8mb4（别混latin1） - 别试图拖动滑块或手动填“65535”来绕过——Navicat会静默拒绝
怎么让DYNAMIC真正生效，而不是被静默降级？
执行ALTER TABLE your_table ROW_FORMAT = DYNAMIC只是表面动作，底层依赖innodb_file_per_table=ON。若该参数为OFF，DYNAMIC会被强制回退成COMPACT，错误照旧。
- 先确认：
SELECT @@innodb_file_per_table;返回1才安全 - MySQL 5.7.7+ 和 8.0+ 不需要设
innodb_file_format，设了也无效；5.6.3–5.7.7需同时确保innodb_file_format=Barracuda（但Navicat设计界面改不了这个） - 大表执行
ALTER可能锁表较久，建议低峰期操作，并提前ANALYZE TABLE your_table;更新统计信息，否则优化器仍按旧行大小估算执行计划
导入.sql文件时批量修复，而不是一张张ALTER
如果你是从备份文件（如20260615.sql）导入崩了，别手工改每张表——用文本编辑器全局替换更稳：
- 搜索
ENGINE=InnoDB，替换成ENGINE=InnoDB ROW_FORMAT=DYNAMIC - 搜索
ROW_FORMAT=COMPACT或ROW_FORMAT=REDUNDANT，全部替换成ROW_FORMAT=DYNAMIC - 删掉文件头部的
SET SESSION innodb_strict_mode = 0;——它不会让建表成功，只会让后续查询返回NULL掩盖问题
真正容易被忽略的是：即使你把所有大字段都换成了TEXT，如果表里还有三十多个VARCHAR(255)，加上utf8mb4和NULL位图，依然可能触达65535上限。这时候得回头删冗余字段，或者拆表——类型切换只是第一刀。
