必须在navicat连接高级设置中手动添加&servertimezone=asia/shanghai&usetimezone=true（mysql 5.7/8.0）或&servertimezone=gmt%2b8&usetimezone=true（云数据库），并重新输入密码使参数生效，否则同步timestamp字段会变null或偏移8小时。
必须在连接的「高级」页手动加参数，不能依赖系统时区或会话级 SET time_zone —— 否则同步 TIMESTAMP 字段时大概率变 NULL 或偏移 8 小时。
MySQL 连接高级设置里怎么填时区参数
Navicat 16+ 不提供图形化时区下拉框，serverTimezone 必须手写进连接字符串。常见错误是只设 useTimezone=true 却漏掉 serverTimezone，这会导致参数不生效。
- 对 MySQL 5.7 / 8.0，推荐在连接字符串末尾追加：
&serverTimezone=Asia/Shanghai&useTimezone=true - 连阿里云 RDS 或腾讯云 CDB 时，部分环境要求 URL 编码：
&serverTimezone=GMT%2B8&useTimezone=true（注意%2B是+的编码） - 改完后必须右键连接 → 「编辑连接」→ 重新输入密码，否则 Navicat 会复用旧握手缓存，新参数不加载
- 验证是否生效：连上后执行
SELECT @@time_zone, NOW(), SYSDATE();，三者返回时间应一致且落在东八区范围内
为什么 SET time_zone = '+08:00' 同步前执行没用
因为 Navicat 同步功能（Data Sync）会新建独立会话执行 SQL，不继承你当前查询窗口的会话设置。你在普通查询里执行的 SET 对同步过程完全无效。
- 同步预览中看到
created_at显示为NULL，但源库有值 → 典型是客户端时区未对齐，导致 MySQL 把非 UTC 时间误判为非法值 - 目标库该字段比源库早/晚 8 小时 → 源库存的是 UTC，Navicat 用本地时区（比如系统设成 UTC）去解释，结果少 8 小时
- 报错
Incorrect datetime value: 'NULL'，尤其在STRICT_TRANS_TABLES模式下 → 本质是时区错位触发了严格校验失败
同步前还要检查哪些隐性时区陷阱
光配对连接参数还不够，MySQL 服务端本身的状态也会影响同步行为。
- 检查表定义：
SHOW CREATE TABLE your_table;确认TIMESTAMP字段没带DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP以外的隐式行为（如NOT NULL但无默认值） - 确认 SQL mode：
SELECT @@sql_mode;若含NO_ZERO_DATE或STRICT_TRANS_TABLES，时区错位更容易直接报错而非静默修正 - 验证
explicit_defaults_for_timestamp设置：SELECT @@explicit_defaults_for_timestamp;应为ON，否则老版本兼容逻辑可能干扰 TIMESTAMP 解析 - 别信
SELECT NOW()单条结果 —— 它受会话时区影响；真正要看的是SELECT @@global.time_zone, @@session.time_zone;是否都稳定为+08:00或Asia/Shanghai
最容易被忽略的是：MySQL 服务端的 default-time-zone 配置和 Navicat 连接参数必须方向一致。服务端设成 +08:00，客户端却填 Asia/Shanghai，某些旧版驱动会解析失败 —— 不是所有环境都支持时区名称，数字偏移最稳。
