同步前需用SQL批量查出目标库中长度不足的VARCHAR字段并扩长，如执行SELECT CONCAT('ALTER TABLE ',table_name,' MODIFY ',column_name,' VARCHAR(1000);') FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema='db' AND data_type='varchar' AND character_maximum_length<1000；改后须刷新连接以更新Navicat缓存元数据。
Navicat同步前怎么查出所有VARCHAR字段并批量扩长
navicat 同步时字段截断，往往不是同步过程出错，而是目标表字段长度比源数据小。它不会报错，只静默丢后半截——比如源字段有 800 字符，目标却是 varchar(255)，那从第 256 个字开始全没了。所以得在同步前动手改结构，而不是等同步完再补救。
关键不是“一个个改”，而是用 SQL 批量捞出所有需要动的列：
- 连上目标库，执行：
SELECT CONCAT('ALTER TABLE `', table_name, '` MODIFY `', column_name, '` VARCHAR(1000);') AS stmt FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = 'your_db_name' AND data_type = 'varchar' AND character_maximum_length < 1000; - 把结果复制出来，人工扫一遍：确认哪些表真要同步、哪些是日志表或临时表，别误伤
-
VARCHAR(1000)不是万能值，得看业务。用户地址可能要 2000，但用户名 200 就够；超过 3072 字节（InnoDB 单字段限制）会自动转为TEXT，但索引会失效
同步中途发现字段太短，还能不能热修复
能，但必须停任务、改结构、再手动续传。Navicat 不支持边同步边改字段长度——ALTER 操作会锁表，同步线程卡住，强行继续只会报错 ERROR 1213（死锁）或 ERROR 2013（连接丢失）。
- 先暂停同步任务（不是取消，是点暂停按钮）
- 在目标库执行
ALTER TABLE t MODIFY col VARCHAR(2000)，确保该列没被其他事务长期占用 - 回到 Navicat，进同步配置 → 高级 → 勾选「使用 SQL WHERE 条件」，填入类似
id > 123456（你刚看到最后成功插入的 ID） - 别直接点“开始”，先点「预览」看生成的 INSERT 语句是否还含截断风险——如果源字段用了
TEXT，而目标仍是VARCHAR，预览里会暴露长度警告
为什么改了目标字段长度，同步还是截断
常见原因是 Navicat 缓存了旧的表结构元数据，尤其在结构同步没跑完、或 Profile 复用时。它读的是本地缓存的列定义，不是实时查 INFORMATION_SCHEMA。
- 改完字段后，必须右键目标连接 → 「刷新」，强制重载元数据
- 如果用了 Profile，Load 后务必进「表映射」页，点开任意一列的「编辑映射」，看「目标字段」下拉框里显示的长度是不是新值——有时候界面没刷新，显示的还是 255
- 更彻底的办法：删掉当前同步任务，新建一个，别复用旧 Profile；否则字段类型可能按旧缓存硬编码进同步逻辑里
TEXT 和 VARCHAR 到底该选哪个
别无脑全换 TEXT。虽然它上限大（65535 字节），但代价明显：
-
TEXT字段不能设默认值（MySQL 5.7+ 对TINYTEXT等例外，但不通用） - 索引只能建前缀，比如
INDEX(col(255))，搜全文效率低 - Navicat 同步时对
TEXT的处理更保守，某些版本会额外加TRIM()或转义，反而引入空格或乱码 - 真正该用
TEXT的，只有富文本、日志、JSON 字符串这类明确超长且不参与 WHERE/JOIN 的字段
多数业务字段，VARCHAR(1000) 足够，也最可控。扩长这事，宁可多试两次 ALTER，别图省事一步到位全切 TEXT。
