Navicat 导入日期字段毫秒丢失，需三步解决：①导入向导中为日期列指定格式“yyyy-MM-dd HH:mm:ss.SSS”；②确保数据库字段支持毫秒（如MySQL用DATETIME(3)、Oracle用TIMESTAMP(3)、SQL Server用DATETIME2(3)）；③检查CSV无BOM、隐藏字符及引号干扰。
Navicat 导入时日期字段被截断，毫秒丢失
navicat 默认按 yyyy-mm-dd hh:mm:ss 解析时间，遇到 2023-10-05 14:22:33.456 这类带毫秒的字符串，会直接丢弃 .456 部分，存进数据库变成秒级精度。这不是数据损坏，而是导入时解析规则没匹配上。
根本原因是 Navicat 的「日期时间格式」识别依赖你手动指定格式模板，它不会自动探测毫秒存在与否。
- 确认源数据中日期列是文本格式（如 CSV 或 Excel 中显示为
2023-10-05 14:22:33.456），而非已转成 Excel 序列号或本地化时间戳 - 在 Navicat「导入向导」第 3 步（字段映射）中，找到对应日期列 → 点击右侧「…」→ 弹出「日期时间格式」对话框
- 输入精确格式：
yyyy-MM-dd HH:mm:ss.SSS（注意大小写：小写yyyy、dd，大写HH表示 24 小时制，SSS表示毫秒） - 如果数据库是 MySQL，确保目标字段类型是
DATETIME(3)或TIMESTAMP(3)，否则即使导入成功，毫秒也会被数据库截断
MySQL 目标表字段不支持毫秒，导入后仍无毫秒
即使 Navicat 正确解析了毫秒，如果目标字段定义是 DATETIME（无精度），MySQL 会静默丢弃毫秒部分。这是数据库层限制，和 Navicat 无关。
检查并修正字段定义：
- 执行
SHOW CREATE TABLE your_table;查看当前定义 - 若字段是
DATETIME，需改用DATETIME(3)（支持最多 3 位毫秒） - 修改语句示例：
ALTER TABLE your_table MODIFY created_at DATETIME(3); - PostgreSQL 用户注意：
TIMESTAMP WITHOUT TIME ZONE默认支持微秒，但 Navicat 导入时仍需指定yyyy-MM-dd HH:mm:ss.SSS格式才能正确映射
CSV 中日期含毫秒但 Navicat 提示“日期格式错误”
常见于 Windows 记事本保存的 CSV：换行符或 BOM 头干扰解析；或者日期字符串里混入不可见空格（如全角空格、\u200b 零宽字符）。
实操建议：
- 用 VS Code 或 Notepad++ 打开 CSV，切换到「显示所有字符」模式，检查日期前后是否有异常空格或符号
- 确保 CSV 中日期列没有引号包裹（如
"2023-10-05 14:22:33.456"），Navicat 对带引号的 datetime 字符串有时无法匹配格式模板 - 临时把该列复制到新 Excel 表，设置单元格格式为「文本」，再另存为 CSV（UTF-8 无 BOM），可规避编码问题
- 如果仍失败，先在 Navicat 中将该列映射为
VARCHAR类型导入，再用 SQL 更新转换：UPDATE t SET dt_col = STR_TO_DATE(dt_col, '%Y-%m-%d %H:%i:%s.%f');
Oracle / SQL Server 导入毫秒失败的特殊处理
Oracle 要求毫秒格式必须是 YYYY-MM-DD HH24:MI:SS.FF3，SQL Server 则接受 yyyy-MM-dd HH:mm:ss.fff，但 Navicat 的格式框只认 Java SimpleDateFormat 语法（即 SSS），不是数据库原生语法。
所以关键点只有一个：Navicat 侧统一用 yyyy-MM-dd HH:mm:ss.SSS，数据库侧确保字段支持毫秒（Oracle 用 TIMESTAMP(3)，SQL Server 用 DATETIME2(3)）。
- Oracle 用户注意：
TO_DATE()不支持毫秒，必须用TO_TIMESTAMP()，因此导入时务必选对目标字段类型，不能是DATE - SQL Server 若目标字段是
DATETIME（非DATETIME2），即使 Navicat 解析出毫秒，也会被 SQL Server 四舍五入到 .000/.003/.007 秒，这是 SQL Server 旧类型的固有限制 - Navicat 版本低于 15.0.24 时，对 SQL Server 的
DATETIME2毫秒映射有 bug，建议升级
