Null

作者：秦福朗 爱可生 DBA 团队成员，负责我的项目日常问题解决及公司平台问题排查。酷爱互联网，会摄影、懂厨艺，不会厨艺的 DBA 不是好司机，didi~ 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明来>源。 背景一个业务零碎刚迁徙完，笔者刚回到家，开发那边就遇到了业务报错”Column ‘create_time’ cannot be null”，从字面意思能够了解为表字段’create_time’想插入null值，但报错该字段不能为null。由此引发了对explicit_defaults_for_timestamp这个无关工夫参数的思考。 概念概述1. TIMESTAMP和DATETIME提 explicit_defaults_for_timestamp 参数，首先就要简略解释下工夫数据类型 TIMESTAMP 和 DATETIME ： TIMESTAMP 是一个工夫戳，范畴是'1970-01-01 00:00:01.000000'UTC 到'2038-01-19 03:14:07.999999'UTC。DATETIME是日期和工夫的组合，范畴是'1000-01-01 00:00:00.000000'到 '9999-12-31 23:59:59.999999'。TIMESTAMP 和 DATETIME 列都能够主动初始化并且能够更新为以后的日期和工夫，列还能够将以后的工夫戳指定为默认值、自动更新的值或者两个同时应用都能够。 2. explicit_defaults_for_timestamp这个零碎变量决定了 MySQL 是否为 TIMESTAMP 列的默认值和 NULL 值的解决启用某些非标准的行为。在 MySQL5.7 的默认状况下，explicit_defaults_for_timestamp 是禁用的，这将启用非标准的行为。在 MySQL8.0 的默认值是开启的。本文默认在 MySQL5.7 场景下。 看场景 业务报错”Column ‘create_time’ cannot be null”，该列不能插入 null 值，查看一下表构造： #只展现局部工夫相干列`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创立工夫',`update_time` timestamp NULL DEFAULT NULL COMMENT '更新工夫',能够看到 create_time 列的属性是 not null ，依照惯性思维想，此列不应该插入 null ，为何之前的环境是没有问题的呢？经查看参数发现问题出在 explicit_defaults_for_timestamp 参数上，在迁徙前零碎没有独自设置该参数值，从 MySQL5.7 的官网文档可知，此时应用默认值为 OFF ，在迁徙后的新零碎应用的爱可生的 DMP 数据库运维平台的默认 MySQL5.7 配置文件，此时配置文件是配置了该参数值为 ON 。 ...