Navicat导入TXT无表头时字段顺序错乱，应二选一：手动拖拽调整字段映射顺序，或在文件首行添加占位表头并勾选“第一行包含字段名”；编码须统一为UTF-8无BOM，大文件应改用数据库原生命令。
字段顺序错乱或第一行被当数据怎么办
Navicat 默认按列位置匹配，不看字段名。TXT 没表头时，它直接把第一行当普通数据塞进表的前几列——哪怕目标表首列是 id（自增主键），也会硬塞一个文本值，立刻报主键冲突或类型错误。
解决方法只有两个，且必须二选一：
- 在导入向导第 2 步「字段映射」里，手动拖拽右侧目标字段，严格对齐 TXT 的列顺序
- 在 TXT 文件最上方加一行占位字段名（如
col1、col2），然后勾选「第一行包含字段名」——这样 Navicat 才会启用名称映射，跳过第一行
注意：加占位名后务必确认 TXT 是纯文本，不能带 Excel 公式、合并单元格或隐藏字符。
中文全变问号或数字小数点丢失
乱码不是 Navicat “没设对”，而是三个环节编码不一致：TXT 文件实际保存编码、Navicat 导入时选的编码、目标表字段的字符集。只要其中一个不匹配，就丢数据。
最稳操作链：
- 用记事本打开 TXT →「另存为」→ 编码选
UTF-8 无 BOM - Navicat 导入向导第 1 步，「文件编码」明确选
UTF-8 - 确认目标表字段字符集是
utf8mb4（MySQL）或UTF8（PostgreSQL），不是latin1或GBK
如果源数据来自 Excel，务必先另存为「文本文件(制表符分隔)(*.txt)」，再执行上述另存为 UTF-8 步骤——Excel 默认导出的 TXT 是 ANSI 编码。
导入卡死、内存不足或几十万行就崩
Navicat 不是 ETL 工具，它的 TXT 导入走本地内存解析，50 万行以上大概率触发 OOM 或假死。这不是调参数能绕开的设计限制。
真要导大文件，别在图形界面硬扛：
- 先导出为规范 CSV（引号包裹、无换行、逗号分隔），再用数据库原生命令：
LOAD DATA INFILE（MySQL）、COPY（PostgreSQL） - 或者在 Navicat 里改用「工具 → 数据传输」，它底层调用服务端批量接口，不依赖本地内存
- 临时提速可关掉「启用日志记录」和「验证数据完整性」，但仅对小文件有效
另外，勾选「忽略重复记录」只跳 UNIQUE 冲突，PRIMARY KEY 冲突仍会中断整个批次——这点容易被误判为“设置没生效”。
时间字段含“年/月/日”格式却插不进
Navicat 不会自动识别中文日期格式。比如 TXT 里是 2026年09月07日 15:30:00，而目标字段是 DATETIME，不指定格式就会全转成 0000-00-00 00:00:00 或直接报错。
必须在「高级设置」里手动填日期格式字符串：
-
yyyy年MM月dd日 HH:mm:ss（对应上面例子） -
yyyy/MM/dd HH:mm、dd-MM-yyyy等，严格按 TXT 实际格式写，字母大小写敏感
如果格式混杂（比如部分行是 YYYY-MM-DD，部分是 DD/MM/YYYY），Navicat 无法自动适配——得先用脚本或 Excel 统一格式，再导入。
