同步时日期截断为0000-00-00是因sql_mode启用NO_ZERO_DATE等限制；Navicat将空/非法日期转为0000-00-00被MySQL拒绝，需预处理替换为NULL或临时调整sql_mode；日期解析错误源于分隔符与顺序不匹配，须严格对应源格式；时区偏差需设置timezone；毫秒丢失需字段定义DATETIME(3)、映射勾选允许小数秒且源数据含小数点。
同步时时间字段被截断或变成 0000-00-00
这是 sql_mode 中启用了 no_zero_date 或 no_zero_in_date 导致的。navicat 在同步过程中若遇到 excel 或 csv 里空日期、非法日期（如 00/00/0000、1900-00-00），会默认转成 0000-00-00，而 mysql 拒绝写入。
解决方法不是在字段映射里“转换格式”，而是提前过滤或替换非法值：
- 在 Navicat “数据传输”向导的「高级」选项中勾选 “忽略错误行”（慎用，可能丢数据）
- 改用预处理：把源 Excel 中空日期统一填为
NULL，或用公式=IF(ISBLANK(A1),"NULL",TEXT(A1,"yyyy-mm-dd"))输出标准文本 - 若已同步失败，临时关闭限制：
SET SESSION sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
字段映射里选了 YMD 还是错，比如 2023/05/12 变成 2023-12-05
Navicat 的日期解析依赖两个关键设置：分隔符 + 顺序，且**顺序优先级高于分隔符**。即使你选了 YMD，如果实际数据用的是 /，而你在映射界面误选了 - 作分隔符，它仍会按 Y-M-D 解析，但把 05/12 当成 月/日 → 错判为 12 月 5 日。
正确操作步骤：
- 先确认源数据真实格式：选中 Excel 中一列日期单元格 → 右键「设置单元格格式」→ 看“类型”显示的是
YYYY/MM/DD还是MM/DD/YYYY - 在 Navicat 字段映射页，对应该列点击「编辑」→ 顺序选
YMD或MDY，分隔符必须和源数据完全一致（比如源是2023/05/12，就选/，不能选-） - 勾选
Use default value for empty string并设为NULL，避免空字符串触发默认零日期
同步后时间比预期少 8 小时（尤其 PostgreSQL）
这不是字段映射能解决的问题。PostgreSQL 的 timestamp without time zone 类型本身不存时区，Navicat 客户端读取时会按本地系统时区解释——如果你系统时区是 UTC，而数据库存的是 Asia/Shanghai 时间（即东八区），就会显示少 8 小时。
验证方式：SHOW timezone; 查看当前会话时区；再执行 SELECT now(); 对比服务器时间和 Navicat 显示时间差。
临时修复（每次连接都要运行）：SET timezone = 'Asia/Shanghai';
长期方案：
- 在 Navicat 连接属性 → 「高级」页签 → 勾选
Execute command on connect，填入SET timezone = 'Asia/Shanghai'; - 或直接改 PostgreSQL 配置：修改
postgresql.conf中timezone = 'Asia/Shanghai'，重启服务
目标字段是 DATETIME 但同步后秒数丢失（如 14:30:22.123 → 14:30:22）
MySQL 的 DATETIME 默认精度是秒级，不带毫秒。如果你源数据含毫秒（如 Excel 里导出的 2023-05-12 14:30:22.123），Navicat 会自动截断，且不会报错。
要保留毫秒，必须满足三个条件同时成立：
- 目标字段定义为
DATETIME(3)（括号内数字表示微秒位数，支持 0–6） - Navicat 字段映射中，该列类型手动指定为
DATETIME，并勾选Allow fractional seconds - 源数据中的时间字符串必须含小数点，例如
"2023-05-12 14:30:22.123"，不能是 Excel 自动格式化后的无小数显示
最容易被忽略的是第三点：Excel 单元格即使存了毫秒，在常规显示模式下也看不到小数点，得用公式 =TEXT(A1,"yyyy-mm-dd hh:mm:ss.000") 强制输出完整精度后再导出。
