根本原因是主库触发器中now()依赖的时区上下文（system/global/session/jdbc四层）未对齐，导致错误时间写入后被row模式从库直接回放，无法修正。
触发器里用 NOW() 或 CURRENT_TIMESTAMP 生成的时间不准确，根本原因不是触发器本身“写错了”，而是它在主库执行时依赖的时区上下文和应用层透传时间不一致，且该行为在主从复制中不会被同步修正——你看到的是主库那一刻的本地解释结果，而从库根本不运行触发器，更不会帮你“重算”。
触发器时间不准，本质是时区链路断裂
触发器里的 NOW() 永远按主库当前会话的 time_zone 计算。但这个“当前会话时区”可能来自四层之一：system_time_zone、@@global.time_zone、@@session.time_zone、JDBC 的 serverTimezone 参数。只要其中任意一层没对齐（比如 MySQL 配了 +08:00，但 Java 应用连接串漏了 serverTimezone=Asia/Shanghai），NOW() 就会返回错误时间值；而这个错误值一旦写入，就固化在主库数据里，从库照单全收。
- 检查命令必须跑全：
SELECT @@global.time_zone, @@session.time_zone, @@system_time_zone;+ 终端执行timedatectl | grep "Time zone" -
SHOW VARIABLES LIKE 'time_zone'只查会话层，容易误判 - JDBC 连接字符串中
serverTimezone缺失或写成GMT+8（未 URL 编码）是高频错误点
ROW 模式下触发器不执行，但时间误差已铸成
MySQL 主从默认 binlog_format = ROW，从库压根不执行触发器——这是正确设计，不是缺陷。但很多人误以为“从库不跑触发器=时间逻辑干净”，其实大错特错：触发器在主库事务内调用 NOW() 时，已经把错误时间写进目标表了。从库只是忠实地回放那条带错误时间的 Write_rows_log_event，毫无修正能力。
- 用
SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 20确认是否为 ROW 格式（看是否有Table_map_log_event和Write_rows_log_event） - 不要试图在从库改
time_zone来“修复读出来的时间”——DATETIME字段不转换，改了也白改 - 若字段是
TIMESTAMP，则从库查询时会按从库自己的time_zone二次转换，导致主从查同一行显示不同字面值，更混乱
比修触发器更有效的做法：绕开它
与其花半天调试四层时区，不如让触发器彻底不碰时间生成逻辑。真正可控的方式，是把时间生成权交给应用层统一管理，并显式透传。
- 把触发器中的
NOW()全部替换为接收参数，例如INSERT INTO log_table (created_at) VALUES (?);，由应用传入校准时区后的时间戳 - 所有新表字段类型强制用
DATETIME，禁用TIMESTAMP——避免隐式转换带来的不可控 - 已有
TIMESTAMP字段且已出问题？别直接改字段类型，先用CONVERT_TZ(created_at, '+00:00', '+08:00')验证偏差，再批量更新
最易被忽略的一点：即使你把所有配置都设成 +08:00，只要应用层传入的是字符串格式时间（如 "2026-09-02 18:46:00"），JDBC 驱动仍可能按 JVM 本地时区解析后再发给 MySQL——此时 serverTimezone 参数才真正起效。不验证闭环，永远不知道时间到底在哪一环歪掉了。
