Navicat导入固定宽度文本需手动启用“固定宽度”模式并拖拽标定列边界，否则字段错位；须匹配真实换行符与编码，关闭“第一行含字段名”，按位置映射字段，大文件建议转CSV或用LOAD DATA处理。
Navicat 导入固定宽度文本时字段错位
navicat 默认按分隔符解析文本，遇到固定宽度（fixed width）格式会直接当“空格分隔”处理，导致字段切歪、数据跨列——比如姓名字段被截成两半，日期字段混进其他数字里。
根本原因是没启用「固定宽度」模式。它不在「字段分隔符」下拉菜单里，而要手动勾选「固定宽度」复选框，然后用鼠标在预览区画出列边界。
- 进入导入向导第 4 步（选择文件后），别急着点「下一步」，先找到右下角的
固定宽度复选框并勾上 - 勾选后，预览窗口会出现可拖拽的竖线，必须手动点击或拖动来标出每列起始位置，不能依赖自动识别
- 第一列从第 1 字符开始，第二列从第
n+1字符开始（n是第一列宽度），以此类推；最后一列默认延伸到行尾 - 如果某列含空格（如地址字段），固定宽度能保住完整性；但若原始文本有换行符嵌在字段中，Navicat 无法处理，需提前清洗
固定宽度导入时编码和换行符不匹配导致截断
固定宽度解析对行尾字符极其敏感：如果文本用 \r\n（Windows），但 Navicat 误判为 \n（Unix），就会把一行当成两行，后续所有列边界偏移。
常见现象是：预览里显示行数翻倍、字段值突然变短、最后几列全为空。
- 在导入向导第 2 步「选择源文件」页面，确认
记录分隔符设置正确：CRLF（Windows）、LF（Linux/macOS）、CR（旧 Mac） - 用记事本或 VS Code 打开 TXT 文件，底部状态栏看实际换行符类型，再对应选择
- 编码必须与文件真实编码一致，
UTF-8（无 BOM）最稳妥；若用 GBK 编码却选了 UTF-8，中文字段宽度计算会出错，直接错位
字段映射阶段忽略列宽定义，仍按名称匹配失败
固定宽度模式下，Navicat 不生成带名字的表头行，所以即使你勾了「第一行包含字段名」，它也找不到字段名——此时映射逻辑退化为纯位置匹配，但用户容易误以为能按名称拖拽。
结果就是：右侧目标字段顺序和左侧源列顺序不一致，数据塞进错误字段（比如把电话号插进生日字段）。
- 务必在「字段映射」页（第 6 步）关闭
第一行包含字段名，否则 Navicat 会强行跳过第一行，导致整批数据上移一行 - 左侧「源栏位」显示的是
Column 1、Column 2… 这些只是占位名，**唯一可靠的方式是按视觉位置拖拽对齐** - 如果表字段数少于文本列数，多余列会被静默丢弃；列数不足则后面字段填 NULL —— 注意
NOT NULL字段会直接中断导入
大文件固定宽度导入卡死或内存溢出
固定宽度解析比 CSV 更耗资源，因为 Navicat 需逐字符扫描定位列边界。超过 10 万行就可能响应迟缓，20 万行以上大概率触发「内存不足」弹窗。
这不是配置能调出来的，是解析引擎限制。
- 避免在 Navicat 图形界面硬扛超 5 万行的固定宽度文件
- 临时方案：用 Python 脚本按宽度切分后转成 CSV，再用 Navicat 导入（示例：
line[0:10]取前 10 字符作为第一列） - 生产环境建议绕开 Navicat：MySQL 用
LOAD DATA INFILE配合FIELDS TERMINATED BY ''和LINES TERMINATED BY '\r\n'，再靠SUBSTRING()在 SQL 里切字段
