导出数据时必须确认连接状态、权限和编码；导入前需核对字段顺序与类型；跨库迁移要处理类型映射与默认值；团队协作须规范文件命名、注释说明及敏感数据脱敏。
导出数据时必须确认的三件事
导出前不检查连接状态、权限和编码，后续导入大概率失败。navicat 不会主动报“无导出权限”，而是静默跳过部分表或导出空文件。
- 右键目标表 →
导出向导→ 第一步就显示当前连接用户是否有SELECT权限；若没权限，需 DBA 授权，不能靠“重连换账号”绕过 - 导出格式选
CSV时，务必勾选导出查询结果（不是导出建表语句），否则导出的是空结构 - 中文字段/值乱码的根源几乎都在编码：导出对话框中
字符集必须选UTF-8 with BOM，尤其当接收方用 Windows 上的 Excel 或 WPS 打开时；纯UTF-8在这类软件里默认按 ANSI 解析，汉字全变问号
导入 CSV 到目标表前的字段映射陷阱
Navicat 的导入向导看似自动匹配字段名，但实际只按“顺序+类型”粗略对齐，名称不一致或顺序错位就会写错列。
- 导入前先在目标库执行
DESCRIBE table_name，记下字段顺序和类型；对比 CSV 头行，确保二者完全一致——比如源 CSV 是user_id,name,created_at，而目标表是id,full_name,create_time，就不能依赖自动映射 - 日期字段最易出错：
2025-03-12可能被识别为字符串，需手动在导入向导第二步中将对应列类型设为DATE，并指定格式为Y-m-d - 含逗号的文本字段（如地址、备注）必须用双引号包裹，且导出时要勾选
使用引号包围字段，否则 Navicat 会把一个字段切分成多列
跨数据库类型传输（如 MySQL → PostgreSQL）要处理的兼容性问题
Navicat 的 数据传输 功能支持异构迁移，但不会自动转换语法和类型，卡点集中在数据类型映射和默认值上。
-
TINYINT(1)在 MySQL 中常作布尔用，但 PostgreSQL 没该类型，传输后变成smallint，应用层读取可能报类型不匹配；建议提前在目标库建表时用BOOLEAN，并在传输设置中取消勾选创建目标表 - MySQL 的
NOW()默认值在 PostgreSQL 中不生效，传输后字段变成NULL；需在目标表手动加DEFAULT NOW()，或改用 Navicat 的结构同步工具先对齐 DDL - 大文本字段如
TEXT/MEDIUMTEXT传到 PostgreSQL 后统一成text，没问题；但 MySQL 的ENUM会变成varchar，枚举约束丢失，得人工补CHECK约束
团队协作中容易被忽略的元数据同步方式
Navicat 本身不传“谁导的、什么时候导的、为什么改了这列”，这些信息只能靠外部约定落地。
- 每次导出 CSV 前，在文件名里嵌入时间戳和来源标识，例如
user_base_20260602_mysql_to_pg.csv，避免多人覆盖同一文件 - 在 CSV 文件第一行列出变更说明，用注释行开头（Navicat 导入时会跳过以
#开头的行）：# 来源：CRM系统v2.3，已脱敏手机号，address字段合并了省市区 - 如果传输涉及敏感字段（如身份证、手机号），不要依赖 Navicat 的“导出时加密”选项（它只加密文件本身，不脱敏内容），必须在导出前用 SQL 查询做
REPLACE(id_card, SUBSTR(id_card, 3, 8), '********')类处理
真正难的不是点击“开始传输”，而是让接收方拿到文件后不用再猜字段含义、不用重试三次才调通编码、不用翻聊天记录找脱敏规则。这些细节不写进操作文档，下次交接照样卡住。
