还原时区敏感的 TIMESTAMP 数据前，必须确保 MySQL 服务端 time_zone 与源库一致，并用 UNIX_TIMESTAMP 验证真实值，同时区分 TIMESTAMP（自动时区转换）与 DATETIME（无转换）的行为差异。
还原时区敏感的 TIMESTAMP 数据前，先确认 MySQL 服务端时区设置
navicat 本身不处理时区转换，它只是把客户端传来的值原样发给 mysql。真正决定 timestamp 如何存储和展示的是 mysql 服务端的 time_zone 配置。如果备份文件里存的是 utc 时间（比如 mysqldump 默认行为），而还原时 mysql 的 time_zone 是 +08:00，那查询结果会自动转成东八区时间——但底层存储仍是 utc，只是显示偏移了。
检查方法：
SELECT @@global.time_zone, @@session.time_zone;还原前务必让目标库的
time_zone 和源库一致，或明确知道差异。否则即使 Navicat 显示“成功还原”，时间值也可能错位 8 小时。
用 Navicat 导入 SQL 文件时，避免 SET time_zone 被忽略
有些 mysqldump 生成的备份文件开头带 SET time_zone = '+00:00'; 这类语句。Navicat 在执行导入时，默认会跳过这类会话级设置语句——尤其当你选的是“运行 SQL 文件”而非“还原备份”功能时。
- 优先使用 Navicat 的 “还原”功能（右键连接 → “还原”），它会更严格地模拟 mysqldump 恢复流程，保留
SET time_zone - 如果必须用“运行 SQL 文件”，手动在 SQL 文件最顶部加一行：
SET time_zone = '+00:00';（替换成你备份时的实际时区） - 检查 Navicat 的“SQL 文件”导入选项：取消勾选“忽略错误继续执行”，否则
SET time_zone报错（如权限不足）会被静默跳过
TIMESTAMP 列在 Navicat 表结构编辑器里显示为本地时间，但这不是真实存储值
Navicat 查看表数据时，默认把 TIMESTAMP 当作本地时间渲染（受客户端系统时区影响），容易误判还原是否正确。比如服务器存的是 2023-01-01 00:00:00（UTC），你本地是东八区，Navicat 就显示成 2023-01-01 08:00:00——但实际存储没变。
验证真实值的方法：
- 在 Navicat 查询窗口执行：
SELECT UNIX_TIMESTAMP(your_timestamp_col), your_timestamp_col FROM your_table LIMIT 1;——UNIX_TIMESTAMP返回的是 UTC 秒数，不受任何时区干扰 - 对比源库同一条记录的
UNIX_TIMESTAMP值，相等才说明还原准确 - 不要依赖 Navicat 数据网格里的直观显示做判断
跨时区迁移时，DATETIME 和 TIMESTAMP 的行为差异必须分清
如果原始数据用了 DATETIME 类型，它不自动时区转换，还原后就是字面值；而 TIMESTAMP 总是基于服务器 time_zone 解释。混用二者会导致时间错乱。
常见陷阱：
- 从 UTC 服务器导出的
TIMESTAMP备份，在东八区服务器还原后，若未同步time_zone，查询结果会比预期快 8 小时 - Navicat 的“结构同步”功能默认不比较时区相关元数据，不会提醒你
time_zone不一致 - 用
SHOW CREATE TABLE检查目标表，确认TIMESTAMP列没有被意外改成DATETIME（某些旧版 Navicat 导入时可能类型降级）
时区问题从来不是 Navicat 的 bug，而是 MySQL 存储机制与客户端渲染的叠加效应。盯住 time_zone、验证 UNIX_TIMESTAMP、区分 TIMESTAMP 和 DATETIME 的语义——这三件事漏掉任何一个，时间就大概率对不上。
