Timestamp潜在危险

集团多处提醒：第一列timestamp可能会被MySQL设置为根据当前时间自动更新。

甚至集团都建议：建表的时候time_modified列设置在time_created列之前，我觉得这件事挺不可思议的。

究竟是什么情况下，第一列timestamp会被增加ON UPDATE CURRENT_TIMESTAMP？

MySQL官方文档

原文地址：https://dev.mysql.com/doc/refman/5.7/en/timestamp-initialization.html

explicit_defaults_for_timestamp

一个很重要的系统变量：explicit_defaults_for_timestamp
查询了一下公司目前MySQL该系统变量的值为OFF

白话文

上面的中文是谷歌自动翻译，可能不是很准确，我这边会总结一下，几个关键的问题。

在explicit_defaults_for_timestamp:OFF的情况下，第一列timestamp会同时设置DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP，如果两者都没有明确指定为第一列timestamp。
其实以上这句话已经总结好了，为了解释这句话，下面继续补充了。

• 情况一：explicit_defaults_for_timestamp:ON，由于公司系统变量是OFF，不计划变更系统变量参数，此种情况不分析。
• 情况二：explicit_defaults_for_timestamp:OFF
  • 使用DEFAULT指定
  • 将列设置为可以为NULL，这样会引发一个问题，列可以为NULL的问题。

这是官网的列子。

• 以上三种表结构，第一列timestamp都没有自动初始化或更新。
• t1表NOT NULL，t2、t3 NULL
• t2表定义ts1字段允许NULL，所以默认值也是NULL，只是没有显示的定义DEFAULT NULL。
  t3表字段允许为NULL，默认值显示定义为0。

看到这里我相信你们应该都明白这是怎么回事了。

总结

为了避免第一列timestamp自动更新的情况。
如果第一列timestamp是业务的时间戳，例如：计划开始时间，又不需要默认值，将列设置为可以为NULL。
如果第一列timestamp是创建时间字段，例如：time_created，可以指定为DEFAULT CURRENT_TIMESTAMP。