AWS RDS MySQL 5.6中NOT NULL timestamp字段被意外更新为NULL的原因咨询

碰到这种情况确实挺闹心的——明明依赖数据库自动维护updated_at字段，结果却出现了意外的NULL值。结合你使用的AWS RDS MySQL 5.6环境，我整理了几个最可能的诱因，以及对应的排查方向：

• 显式赋值的疏漏（最常见）：
  虽然你说没有手动维护时间戳，但应用代码或ORM框架很可能在某些场景下“悄悄”生成了带updated_at = NULL的语句。比如：

  • 批量更新操作时，不小心把updated_at字段纳入了更新列表，并且赋值为NULL；
  • ORM配置出错，比如部分字段更新时没有跳过updated_at，反而传入了NULL值；
  • 测试/调试阶段的临时SQL语句没清理，不小心执行了更新NULL的操作。
    建议开启MySQL的通用日志或慢查询日志，捕捉所有修改该表的语句，就能快速定位有没有这类显式赋值的情况。

• MySQL 5.6的已知Bug：
  MySQL 5.6的部分早期版本存在和TIMESTAMP字段ON UPDATE约束相关的Bug，比如：

  • 当表包含多个TIMESTAMP字段时，特定场景下自动更新逻辑失效；
  • 在READ COMMITTED事务隔离级别下，并发更新可能导致字段被设为NULL；
  • 分区表的更新操作中，ON UPDATE CURRENT_TIMESTAMP约束没有正确触发。
    你可以在RDS控制台查看当前MySQL的具体版本，如果是较旧的5.6版本，建议升级到5.6的最新稳定小版本——RDS支持无停机小版本升级，很多这类Bug在后续补丁里已经被修复。

• 触发器的干扰：
  如果你的表上存在BEFORE UPDATE或AFTER UPDATE触发器，一定要检查触发器的逻辑是否会修改updated_at字段。比如触发器里的变量赋值错误、条件判断失误，都可能在某些分支下把updated_at设为NULL。可以用这条SQL查看触发器定义：

  SHOW TRIGGERS LIKE 'your_table_name';
  

  仔细核对触发器中涉及该字段的每一步操作。

• RDS特定操作的异常：
  比如：

  • 快照恢复或备份还原过程中，字段的约束元数据没有被正确恢复，导致ON UPDATE CURRENT_TIMESTAMP失效；
  • 只读副本同步异常：虽然RDS只读副本默认拒绝写操作，但如果有特殊配置（比如跨区域同步的异常场景），可能出现数据不一致的情况，不过这种概率较低。

• 特殊SQL语句的影响：
  比如使用INSERT ... ON DUPLICATE KEY UPDATE时，在MySQL 5.6的某些场景下，可能因为冲突处理的逻辑优先级问题，导致ON UPDATE约束没有触发；或者用LOAD DATA INFILE导入数据时，数据源中的NULL值绕过了默认约束（如果sql_mode没有开启严格模式，比如缺少STRICT_TRANS_TABLES，可能会出现这种情况）。

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