必须勾选「包含列标题」，否则navicat导出csv默认无表头；该选项仅在导出向导的附加选项中生效，且需配合utf-8 bom、逗号分隔符和英文引号限定符才能确保excel正确识别中文列名与结构。
导出时没列名？必须勾选「包含列标题」
Navicat 默认导出 CSV 不带表头，哪怕你右键的是一个结构清晰的表。这不是 bug，是设计行为——它把“导出数据”和“导出元信息”视为两个动作。不手动勾选，导出向导 → 附加选项 → 包含列标题 就永远是关闭状态。
常见错误现象：用 Python pandas.read_csv() 读出来第一行是数据，不是列名；Excel 打开后所有字段左对齐、无表头标识，后续做 GROUP BY 或筛选时容易错位。
- 该选项只在「导出向导」里生效，不在「导出转储」或「计划任务」的快捷入口中暴露
- 如果源表字段名含中文或特殊符号（如空格、括号），务必确认 Navicat 连接的字符集是
utf8mb4，否则列名导出后可能变乱码 - 勾选后，Navicat 实际会在 CSV 第一行写入纯文本字段名，不加引号也不转义——所以字段名里有逗号或换行仍会破坏结构，建议提前清理命名
中文列名乱码？编码设置要同步改两处
Windows 上用 Excel 打开 CSV 显示列名全是问号或方块，大概率是编码没对齐。Navicat 的「文件编码」下拉菜单只是控制写入字节流的编码，而 CSV 格式本身还依赖「文本限定符」和「字段分隔符」的组合才能被正确解析。
真正起作用的组合是：UTF-8 with BOM + 字段分隔符 = , + 文本限定符 = "。缺一不可。
- BOM 是给 Excel 看的“识别信号”，纯 UTF-8 没这个标记，Excel 会默认当 ANSI（即 GBK）解码
- 如果字段分隔符误设为
;（欧洲习惯），很多国内分析工具（如 Power BI、FineBI）会直接报“列数不匹配” - 文本限定符不设为双引号，含换行的中文列名（比如“用户\n备注”）会导致 CSV 解析错行
导出后 Excel 里列宽自动缩成“###”？不是导出问题，是 Excel 自动格式化
导出的 CSV 文件本身没问题，但 Excel 在打开瞬间会按内容自动推测字段类型：手机号、身份证号这类长数字会被转成科学计数法；以 0 开头的编号（如 00123）直接砍掉前导零。这不是 Navicat 导出逻辑缺陷，而是 Excel 的默认行为。
解决方法不是改 Navicat 设置，而是绕过 Excel 直接打开方式：
- 用记事本或 VS Code 打开 CSV，确认内容完整且列名正常——这是验证导出是否成功的黄金标准
- 在 Excel 中用「数据 → 从文本/CSV」导入，手动将每列设为「文本」格式，而非双击直接打开
- 若必须双击打开，可在导出前把数字类字段在 SQL 中转字符串：
SELECT CONCAT('', mobile) AS mobile FROM user_table
想导出多张表的字段说明（comment）？不能靠右键单表，得查系统表
右键一张表 → 导出向导 → 勾选列标题，只能导出那张表的数据行和字段名，拿不到 COLUMN_COMMENT（字段注释）。要生成带业务含义的数据字典 CSV，必须执行元数据查询。
MySQL 示例（在 Navicat 查询窗口运行后导出结果）：
SELECT TABLE_NAME AS `表名`, COLUMN_NAME AS `字段名`, COLUMN_TYPE AS `类型`, IS_NULLABLE AS `是否为空`, COLUMN_COMMENT AS `注释` FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db_name' ORDER BY TABLE_NAME, ORDINAL_POSITION;
导出这个结果集时，仍需回到「导出向导」并手动勾选「包含列标题」——因为这个 SELECT 的字段别名就是你要的列名。
注意：PostgreSQL 写法完全不同，要用 pg_class 和 pg_description 关联；而且 COLUMN_COMMENT 在 MySQL 里是字符串，在 PostgreSQL 里得用 obj_description() 提取，不能照搬。
