导出CSV时必须用制表符分隔并设UTF-8无BOM编码：Navicat导出需手动改分隔符为\t、勾选引号包裹、取消BOM、启用列名首行；日期数字须SQL预处理；禁用Excel导出。
导出 CSV 时必须用制表符而非逗号分隔
Tableau 对 CSV 的字段分隔符非常敏感，尤其当数据含英文逗号、引号或换行时，用默认逗号分隔极易触发解析错误，表现为字段错位、文本截断或日期识别失败。Navicat 导出向导里「分隔符」选项默认是逗号，这恰恰是最容易出问题的设置。
实操建议：
- 在导出向导的「高级选项」页，手动将分隔符改为
\t（制表符） - 同时勾选
使用引号包裹字段值，避免含换行或逗号的单元格被拆开 - 取消勾选
BOM 头，否则 Tableau 可能将 UTF-8-BOM 误判为乱码并跳过首列 - 确认「包含列名作为首行」已启用，否则 Tableau 无法自动映射字段
编码必须选 UTF-8（无 BOM），且不能用 GBK 或 ANSI
Tableau 桌面版（Windows/macOS）默认按 UTF-8 无 BOM 解析文本文件。若 Navicat 导出时选了 GBK 或带 BOM 的 UTF-8，中文字段名或值会显示为方块或问号，且无法通过 Tableau 的“字符编码”下拉菜单临时修正——它只对已加载失败的文件提供重试入口，而首次加载失败后部分元数据已损坏。
关键点：
- 导出格式选
CSV后，在「输出」页明确指定编码为UTF-8，并手动取消添加 BOM勾选（Navicat 默认可能开启） - 不要依赖「自动检测」，Tableau 不会回退尝试其他编码
- 如果源数据本身含 Latin-1 字符（如欧元符号 €），也必须确保数据库连接和 Navicat 客户端都设为 UTF-8，否则导出前就已乱码
日期/数字字段需预处理，避免 Tableau 自动类型转换失败
Navicat 导出时若直接输出 MySQL 的 DATETIME 值（如 2026-10-20 14:35:22），Tableau 有时会识别为字符串而非日期，尤其当某几行为空或格式不一致时。同理，带千分位逗号的数字（如 1,234.56）会被当作文本。
稳妥做法：
- 不在 Navicat 导出界面改格式，而是在导出前用查询定制输出：例如用
DATE_FORMAT(created_at, '%Y-%m-%d')或CAST(price AS DECIMAL(10,2)) - 避免导出 NULL 值为空字符串，Tableau 对空字符串和 NULL 的处理逻辑不同；可用
IFNULL(created_at, '1970-01-01')统一兜底 - 导出前检查字段是否含不可见控制字符（如
\r、\u200b），这类字符 Navicat 不过滤，但 Tableau 会中断解析整行
别信「Excel 格式导出」，Tableau 读 Excel 效率低且易丢精度
Navicat 支持导出为 .xlsx，但 Tableau 加载 Excel 文件时会启动 Excel 引擎（即使没装 Excel），且对长文本、合并单元格、公式等兼容性差。更隐蔽的问题是：Excel 导出会把数字自动转为科学计数法（如 123456789012345 → 1.23457E+14），再导入 Tableau 就永久丢失末尾精度。
真实场景建议：
- 坚持用
CSV（制表符分隔 + UTF-8 无 BOM），这是 Tableau 官方文档明确推荐的「最可靠平面文件格式」 - 如需保留多张表关联关系，不要导出多个 Excel 文件，改用 Navicat 导出为
SQL，再在 Tableau 中用「自定义 SQL」连接原库或 SQLite 临时库 - 若必须用 Excel，先导出为 CSV，再用 Excel 手动另存为
.xlsx（确保「保留原格式」未被勾选）
真正卡住人的往往不是导出按钮，而是导出后 Tableau 刷新时那一秒的「未知错误」——它不告诉你哪一行、哪个字符、哪种编码出了问题。所以每次导出前，用文本编辑器（如 VS Code）打开一个 10 行样本，肉眼确认分隔符、BOM、中文、日期格式是否干净，比反复在 Tableau 里重试快得多。
