差异产生的核心原因 #

你遇到的这个问题，本质是MySQL版本差异导致的复制逻辑不同，再加上可能的时区配置不一致共同作用的结果：

1. 基于语句的复制（SBR）的特性
   MySQL 5.5默认使用基于语句的复制（SBR），在这种模式下，主库会把执行的SQL语句写入binlog，从库拿到SQL后会重新执行一遍。对于NOW()这类依赖当前时间的函数，从库会用自己服务器的当前时间来计算，而不是主库的时间。

2. 主从时区/系统时间不一致
   你的主库时间是16:43，从库是22:43，刚好差6小时，说明主从服务器的系统时区或者MySQL的time_zone参数设置不一致。比如主库设置的是东八区（UTC+8），从库可能被设置成了UTC+14（或者反过来，更常见的是从库时区偏东），导致从库执行NOW()时生成的时间比主库晚6小时。

3. 版本差异的隐性影响
   MySQL 5.7默认是混合模式复制（MIXED），但当主库是5.5时，从库会兼容主库的复制模式，沿用SBR。这就导致了5.5和5.7之间的复制依然会触发SBR下的函数重新计算逻辑。

让时间戳保持一致的解决步骤 #

步骤1：统一主从的MySQL时区配置 #

首先要确保主从的time_zone参数完全一致：

• 查看当前时区：在主库和从库分别执行 SELECT @@global.time_zone, @@session.time_zone;
• 修改时区（以设置为东八区为例）：
  1. 临时生效：执行 SET GLOBAL time_zone = '+08:00';（重启MySQL后失效）
  2. 永久生效：在主从的my.cnf（或my.ini）中添加配置：

     [mysqld]
     default-time-zone = '+08:00'
     

  然后重启MySQL服务。

步骤2：切换到基于行的复制（RBR）模式 #

RBR模式下，主库会把数据行的实际变化写入binlog，而不是SQL语句。这样NOW()计算后的具体时间值会直接被复制到从库，从库不需要重新执行函数，自然就不会出现时间差异：

1. 在主库执行：

   SET GLOBAL binlog_format = 'ROW';
   

2. 永久生效：在主库的my.cnf中添加：

   [mysqld]
   binlog_format = ROW
   

   重启主库，从库会自动同步这个模式（因为从库是5.7，完全支持RBR）。

步骤3：同步主从服务器的系统时间 #

即使MySQL时区配置正确，如果服务器系统时间本身不同步，也可能出现问题。建议在主从服务器上配置NTP服务，确保系统时间精确同步。比如在Linux上可以使用ntpd或chrony服务。

步骤4：修复现有数据的时间差 #

对于已经存在时间差异的数据，可以通过SQL语句批量修正。比如假设表名为your_table，时间戳字段为update_time，可以执行：

UPDATE your_table SET update_time = DATE_SUB(update_time, INTERVAL 6 HOUR);

（注意：执行前先备份数据，并且要确保这个修正逻辑符合你的实际时区差）

内容的提问来源于stack exchange，提问作者TH1981