MySQL主从time_zone不一致会导致基于时间戳的复制逻辑错误，必须在my.cnf中为主从库统一配置default-time-zone='+08:00'并使用ROW格式binlog，同时避免在SQL中使用NOW()等动态函数。
MySQL主从库time_zone不一致导致同步异常
主从时间不同步，最直接的后果是基于时间戳的复制（如ROW格式下含NOW()、CURRENT_TIMESTAMP的语句）在从库回放时产生偏差，甚至触发主键冲突或数据错乱。这不是延迟问题，而是逻辑错误。
-
time_zone是会话级变量，但复制时从库默认用自身全局time_zone解析binlog中的时间值，若与主库不一致，INSERT INTO t VALUES (NOW())在从库可能写入相差1小时的时间 - 常见错误现象：
SHOW SLAVE STATUS\G里没报错，但SELECT查到的时间字段和业务预期不符；使用pt-table-checksum发现时间列校验失败 - 不要依赖应用层传入“已格式化时间字符串”，MySQL内部仍会按当前
time_zone做转换
统一设置default-time-zone比改time_zone变量更可靠
只在启动时设time_zone变量（比如SET GLOBAL time_zone = '+08:00'）不够：从库重启后恢复默认值，且该设置不作用于复制SQL线程——它用的是配置文件里的default-time-zone。
- 必须在
my.cnf中为**主库和从库**都显式配置：[mysqld] default-time-zone = '+08:00'
- 避免用
SYSTEM：它绑定系统时区，而Linux系统时区可能被运维无意修改，且Docker容器里常为UTC - 不要写
Asia/Shanghai：虽然合法，但部分MySQL版本（尤其是5.7旧版）对命名时区支持不稳定，且需额外加载时区表（mysql_tzinfo_to_sql），增加维护负担 - 配置后需重启MySQL，
SELECT @@global.time_zone, @@session.time_zone;确认返回+08:00而非SYSTEM
检查binlog格式与时间函数的组合风险
即使time_zone统一，STATEMENT格式下用NOW()仍可能出问题：主库执行时生成时间字面量，从库按自己时区解释，结果还是错。所以不能只靠时区对齐。
- 强制使用
ROW格式：binlog_format = ROW，让时间值以二进制形式记录，绕过时区解析 - 禁止在写操作中使用
NOW()、CURRENT_TIMESTAMP()等动态时间函数，改用应用层生成UTC时间戳并存入BIGINT或datetime字段 - 如果必须用
datetime类型且依赖默认值，确保字段定义为datetime DEFAULT CURRENT_TIMESTAMP，并确认explicit_defaults_for_timestamp=ON（MySQL 5.7+默认开启），否则隐式行为可能跨版本不一致
验证从库是否真正按预期解析时间
光看@@time_zone值一致还不够，得测binlog回放时的真实行为。最简单的验证方式是模拟一条带时间的语句，观察从库落地结果。
- 主库执行：
CREATE TABLE t_test (ts DATETIME DEFAULT CURRENT_TIMESTAMP); INSERT INTO t_test VALUES (); - 查主库：
SELECT UNIX_TIMESTAMP(ts) FROM t_test;记下数值A - 等同步完成，从库执行同样
SELECT UNIX_TIMESTAMP(ts)，对比是否等于A（注意不是看ts显示值，而是转成Unix时间戳比数字） - 若不等，说明
default-time-zone未生效，或binlog_format仍是STATEMENT
时区配置本身简单，但容易被当成“配完就完事”的一次性操作。真正麻烦的是那些没显式写时区、却依赖默认行为的旧SQL，以及容器化部署中系统时区和MySQL配置的双重干扰——这些点不盯住，同步看似正常，数据其实已经在悄悄偏移。
