timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP 在一台机器上可以为空，但在另一台机器上不能为空？答案

【问题标题】：timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP can be null on one machine but not another?timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP 在一台机器上可以为空，但在另一台机器上不能为空？
【发布时间】：2014-08-04 12:58:03
【问题描述】：

我有一个 MySql 表，其字段定义为：

`created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP

在我的本地机器上，我可以运行：

INSERT INTO mytbl (id, user_id, created) VALUES(88882341234, 765, null);
SELECT id, user_id, created FROM mytbl WHERE id = '88882341234';

然后“创建”将显示类似“2014-06-13 21:16:42”的内容。

但在我的登台服务器上，如果我运行相同的查询，我会收到此错误：

Column 'created' cannot be null.

表的模式是相同的（跨本地和暂存），我通过 mysqldump 确保了这一点（在运行此测试之前克隆表）。

我在两台机器上都运行 MySql 5.6.17。我还确保两者具有相同的 sql_mode。

可能是什么问题？

附：对于不知道我为什么要将不可为空字段的值设置为 null 的人，MySql Docs 说：

此外，您可以将任何 TIMESTAMP 列初始化或更新为当前日期和时间通过为其分配一个 NULL 值，除非它已经使用 NULL 属性定义以允许 NULL 值。

【问题讨论】：

问题可能是查询是错误的，而 MySql 正在本地机器上牵着你的手（我怀疑是由于不同的 SQL 模式有效）。如果created 不能是null，那么你到底为什么要将它设置为null？
我认为这表示将不可为空的时间戳字段的值设置为 null 是让它自动将值设置为当前时间的一种方法：dev.mysql.com/doc/refman/5.5/en/timestamp-initialization.html 所以无论是谁最初编写了这个查询（不是我）可能是故意的。 “不同的 SQL 模式”是什么意思？如何检查和编辑它？
我敢打赌你的意思是dev.mysql.com/doc/refman/5.6/en/sql-mode.html。我会调查的。
我刚刚添加了一个答案。
这台服务器上是否有触发器？确保 mysqldump 中的 --triggers 选项处于活动状态。

标签： mysql

【解决方案1】：

我发现了问题所在。 MySql 变量/参数explicit_defaults_for_timestamp 在我的本地机器上是关闭的，但在我的远程机器上是打开的。

我访问了我的 AWS RDS 参数组页面并将 explicit_defaults_for_timestamp 从 1 更改为 0。然后我去我的 AWS RDS 实例页面查看“参数组”何时从“正在应用”变为“待重启”。然后我重新启动了特定实例。

这些链接帮助了我：

【讨论】：

谢谢，在我的 ubuntu 服务器中使用 mysql 5.6 为我工作。
感谢您发布更新。我们可能需要很长时间才能找到问题！
从传统的 mySQL 服务器迁移到 Amazon RDS 时为我工作。

【解决方案2】：

主要问题是INSERT 是错误的：它试图将NULL 插入到不可为空的列中。

你应该做的只是修复查询：

INSERT INTO mytbl (id, user_id) VALUES(88882341234, 765);

这仅在登台服务器上导致错误的原因是服务器在strict SQL mode 中运行，因此当您尝试将不正确的值插入created 时会立即中止。

您可以使用SELECT @@SESSION.sql_mode 轻松检查有效的 SQL 模式并使用

更改它（也许这样您可以在自己的服务器上重现错误）

SET SESSION sql_mode = 'STRICT_ALL_TABLES'

【讨论】：

不幸的是，我的 2 台服务器已经有相同的 sql_mode，所以这不是问题。而且我不想编辑查询，因为它已经工作了多年（并且仍在我的本地机器上工作）并且本周才突然停止在我的暂存服务器上工作（而且我无法弄清楚是什么用我的登台服务器更改）。不过，感谢您的尝试。
@Ryan：如果它现在不起作用并且您知道它是错误的，那么它多年来一直起作用有什么关系？决定需要修复的损坏需要什么？这是你的代码，是你的选择，但我无法理解这种推理。
它在我的本地机器或生产环境中没有损坏的事实意味着我还不了解问题，而且问题是 Staging 特有的。我永远不想在不了解的情况下更改代码（尤其是当它在生产中为我们赚钱时）。我想弄清楚过去几天发生了什么变化。