Navicat导入毫秒时间戳（如1710512528000）时字段变NULL或乱码，因其不支持自动解析；须提前转为字符串日期格式（如"2024-03-15 14:22:08"），或导入为BIGINT后用FROM_UNIXTIME(created_at/1000)转换。
导入JSON时时间戳是毫秒整数，字段变NULL或乱码
navicat 导入 json 时，如果时间戳是 1710512528000 这种毫秒级数字，它不会自动识别为时间，而是按整数或字符串处理——目标字段为 timestamp 或 datetime 时，直接报错或写成 1970-01-01 08:00:00 类似值。
根本原因不是 Navicat 不支持，而是它没有内置毫秒时间戳解析逻辑。必须提前转换格式：
- 在 JSON 源中把毫秒时间戳转成标准日期字符串，例如
"2024-03-15 14:22:08"或 ISO 格式"2024-03-15T14:22:08" - 如果无法改 JSON，改用 SQL 插入：先导入为临时
BIGINT字段，再用FROM_UNIXTIME(created_at / 1000)转换 - 别依赖「自动类型推断」——导入向导里手动将该字段映射为
VARCHAR，再后续清洗
CSV导入时时间字段变成数字或1970年时间
这是 Navicat 对 TIMESTAMP / DATETIME 字段的默认转换行为：它会尝试用本地时区解释数值型时间戳（如 1710512528），但若没配对时区参数，就容易错算成 Unix 零点偏移后的错误值。
安全做法是绕过自动解析：
- 导入前，在 CSV 中确保时间列是纯字符串格式，如
"2024-03-15 14:22:08"，不要带毫秒、不要用数字 - 导入向导第 2 步「字段映射」中，对该列手动选择类型为
VARCHAR，不选DATETIME - 导入完成后再执行更新语句：
UPDATE your_table SET created_at = STR_TO_DATE(created_at_str, '%Y-%m-%d %H:%i:%s'); - 如果源是毫秒时间戳列，先转成秒：
UPDATE your_table SET created_at = FROM_UNIXTIME(created_at_ms / 1000);
同步或导入时 TIMESTAMP 字段变 NULL 或偏移 8 小时
这不是数据丢了，是 Navicat 客户端和 MySQL 服务端时区没对齐。典型表现：源库值是 2026-07-27 14:00:00，目标库写成 2026-07-27 06:00:00 或直接 NULL。
必须在连接级别强制统一时区：
- 编辑连接 → 「高级」页 → 在「连接字符串」末尾追加：
&serverTimezone=Asia/Shanghai&useTimezone=true - 阿里云 RDS 等环境可能需写成：
&serverTimezone=GMT%2B8（%2B是 URL 编码的+） - 改完后必须右键连接 → 「编辑连接」→ 重输密码，否则旧握手缓存不刷新
- 验证是否生效：连上后执行
SELECT @@time_zone, NOW(), SYSDATE();，三个结果应一致且落在东八区范围
导出再导入后 CURRENT_TIMESTAMP 默认值消失
Navicat「转储 SQL 文件」默认不导出函数类默认值，比如 DEFAULT CURRENT_TIMESTAMP 会被直接省略，导致重建表后时间字段无默认行为。
这不是漏导，是它主动过滤“非标准扩展”：
- 导出时勾选「导出设置」里的「扩展属性」选项（位置在「格式」页下方），才能包含
CURRENT_TIMESTAMP和ON UPDATE - 如果已导出且没勾选，打开 SQL 文件手动补上：
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 注意 MySQL 版本限制：
CURRENT_TIMESTAMP作默认值要求 ≥ 5.6.5；低于此版本只能用触发器或应用层填充 - 字段类型必须是
TIMESTAMP或DATETIME，INT存时间戳填这个默认值会静默失败
useTimezone=true 不生效，只设 serverTimezone 也不生效。这两个参数像开关和档位，缺一不可。 
