Navicat导出TXT实为CSV逻辑，须设制表符分隔、UTF-8编码、启用引号包裹；字段含特殊字符时自动转义符合RFC 4180；大表应分页导出或用命令行；Excel打开需手动导入并选对编码与分隔符。
导出时选错“文本分隔符”导致字段错位
navicat 导出 txt 实际走的是「导出为 csv」逻辑，哪怕你选了 txt 格式，它默认仍用逗号分隔 —— 这在字段含逗号、换行或引号时必然崩。比如 address 字段值是 "北京市朝阳区, 建国路87号\na座"，不加引号包裹就会被拆成三列。
- 务必勾选
使用引号包围字段（即Enclose fields in quotes） - 把分隔符从默认的
,改成更安全的\t（制表符），对应勾选Tab作为分隔符 - 编码选
UTF-8 with BOM或UTF-8，避免中文 Windows 记事本乱码；别用GBK，跨平台读取易出问题
导出结果里多出双引号或转义符
这是 Navicat 对 CSV 规范的严格实现：只要字段含分隔符、换行或引号，就自动加双引号，并对内部引号做转义（如 " → ""）。这不是 bug，是 RFC 4180 要求。
- 如果下游程序（比如 Python 的
pandas.read_csv()）能正确解析 CSV，就别手动删引号 —— 删了反而破坏结构 - 若真要纯无格式文本（比如日志拼接），别用「导出向导」，改用
查询结果 → 右键 → 复制为纯文本，再粘贴到编辑器里保存为 .txt - 注意：复制为纯文本不会保留 NULL 值，会变成空字符串；而导出向导中可设置
NULL value显示为\N或空
大表导出卡死或内存溢出
Navicat 默认把整张表查出来再写文件，10 万行以上、带长文本字段时极易卡在「正在导出」不动，任务管理器里 navicat.exe 内存飙升到 2GB+。
- 先导出前加
LIMIT测试，例如在查询窗口运行SELECT * FROM orders LIMIT 1000，再对结果集导出 - 真正导全量时，用「导出向导」里的
导出查询结果选项，输入带LIMIT和OFFSET的分页 SQL，手动分批导出 - 避开 Navicat 图形界面：用命令行工具更稳，比如 MySQL 客户端执行
SELECT ... INTO OUTFILE '/tmp/data.txt'（需服务端权限），或用mysqldump --tab
导出后用 Excel 打开全是乱码或挤在一列
Excel 默认用系统编码（Windows 是 GBK）打开 TXT，但 Navicat 导出的是 UTF-8，直接双击必然乱码；且没指定分隔符时，Excel 不知道该按 tab 还是逗号切列。
- 不要双击打开导出的 .txt 文件 —— 用 Excel 启动后，
数据 → 自获取外部数据 → 从文本/CSV，手动选编码和分隔符 - 如果坚持双击打开，把文件后缀改成
.csv，并确保导出时用了Tab分隔 +UTF-8 with BOM编码，Windows Excel 才大概率识别正确 - Mac 上用 Numbers 打开更省心，它对 UTF-8 和 tab 分隔天然友好；Linux 下推荐用
less或column -t -s $'\t'查看对齐效果
真正麻烦的不是点几下鼠标，而是导出前得想清楚：下游谁读这个文件？用什么程序？要不要兼容 Excel 双击？有没有特殊字符？这些决定了分隔符、引号、编码、NULL 表示法每一个细节。选错一个，后面花十分钟清理数据的时间就白搭。
