必须在Navicat连接高级设置中显式配置serverTimezone=Asia/Shanghai并启用useTimezone=true，否则TIMESTAMP/DATETIME字段会偏移8小时或变NULL；SQL文件中的SET time_zone无效。
必须在导入前显式设置连接时区，否则 TIMESTAMP 和 DATETIME 字段会稳定偏移 8 小时或变 NULL。
Navicat 导入向导里时间戳变 NULL 或早/晚 8 小时
这是导入时最典型的时区错位现象。根本原因不是数据坏了，而是 Navicat 默认用本地系统时区解析从 MySQL 返回的 TIMESTAMP 值——而 MySQL 服务端默认以 UTC 存储 TIMESTAMP，再按会话时区转换输出。如果 Navicat 连接没指定时区，就会拿错转换基准。
常见表现包括：
- 预览界面中某行
created_at显示为NULL，但源 SQL 文件里明明有值 - 导入后目标库该字段比原始 SQL 里写的值固定早或晚 8 小时（如写的是
'2026-10-21 14:00:00'，入库后变成'2026-10-21 06:00:00'） - 报错
Incorrect datetime value: 'NULL'，尤其在启用STRICT_TRANS_TABLES模式时
导入前必须配置连接高级属性中的 serverTimezone
Navicat 不会自动读取 MySQL 服务端的 time_zone 设置，必须手动告诉它“该用哪个时区解释时间”。关键操作在连接配置里，不是在导入向导中。
操作路径：右键连接 → 编辑连接 → 高级 → 勾选「使用服务器时区」，或更稳妥地：取消勾选，手动填入 serverTimezone=Asia/Shanghai，并确保 useTimezone=true 已启用。
注意以下几点：
- 仅勾选「使用服务器时区」不一定生效，特别是当 MySQL 的
@@global.time_zone是SYSTEM且系统时区未统一时 -
serverTimezone必须写全称（如Asia/Shanghai），不能只写+08:00，否则部分驱动版本会忽略 - 修改后需重新测试连接，再打开导入向导——旧连接不会自动继承新设置
SQL 文件本身带 SET time_zone 声明也没用
很多人会在导出的 SQL 文件开头加 SET time_zone = '+08:00';，但这对 Navicat 导入向导完全无效。因为导入向导不执行 SQL 文件里的会话级命令，它直接解析 INSERT 语句中的字面值，并用当前连接的时区上下文去转换。
所以：
- 别指望靠改 SQL 文件内容来修复时区问题
- 导出时若用了
--set-gtid-purged=OFF或其他参数，也不影响导入时的时区行为 - 如果必须用文件导入，唯一可靠方式是：先用命令行
mysql -u -p --default-character-set=utf8mb4 --server-time-zone='+08:00' db_name 验证正确性，再对比 Navicat 行为
导入后仍偏移？检查目标库表定义和 SQL mode
即使连接时区设对了，如果目标库表结构或环境不一致，仍可能出问题。重点核对：
- 目标表字段是否为
TIMESTAMP类型？DATETIME不受时区影响，但TIMESTAMP会触发自动转换 - 目标库是否启用了
explicit_defaults_for_timestamp=OFF？若为ON，且字段没设默认值，插入NULL可能被转成0000-00-00 00:00:00或报错 - 目标库
sql_mode是否含STRICT_TRANS_TABLES？它会让隐式类型转换失败，直接中断导入 - 目标库全局时区是否与源库一致？查
SELECT @@global.time_zone;，不一致就说明环境没对齐
真正容易被忽略的点是：你改了 Navicat 连接设置，但忘了确认目标 MySQL 实例本身的时区是否真的是 Asia/Shanghai。很多生产库仍保持 SYSTEM 或 UTC，这时候光调客户端没用——得两端都对齐。
