导入SQL Dump至Cloud 9遇MySQL 1067错误：date_time默认值无效

嘿，作为MySQL新手碰到这个问题太正常了，我来帮你捋清楚怎么搞定它！

这个错误的核心原因是Cloud9上的MySQL会话/全局SQL_MODE设置和你本地的不一样。从MySQL 5.7开始，默认启用了NO_ZERO_DATE和NO_ZERO_IN_DATE这两个严格模式规则，它们不允许date_time字段使用'0000-00-00 00:00:00'这类无效日期作为默认值，而你本地的MySQL可能没开这些限制，所以Dump文件在本地能正常运行。

下面是几个可行的解决办法，你可以选最适合你的：

方法1：临时修改会话级SQL_MODE（快速导入） #

先登录Cloud9的MySQL控制台，执行以下命令查看当前的SQL_MODE：

SELECT @@SESSION.sql_mode;

如果结果里包含NO_ZERO_DATE或者NO_ZERO_IN_DATE，就执行这条命令去掉这些限制：

SET SESSION sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

修改完成后，再重新导入你的SQL Dump文件，应该就能成功了。注意这个修改只在当前会话有效，退出MySQL后会恢复原样。

方法2：永久修改全局SQL_MODE（一劳永逸） #

如果以后还要导入类似的Dump文件，可以修改MySQL的配置文件：

1. 打开Cloud9的终端，编辑MySQL配置文件（通常路径是/etc/mysql/my.cnf）：

sudo nano /etc/mysql/my.cnf

2. 在[mysqld]段落里添加或修改sql_mode配置，去掉NO_ZERO_DATE和NO_ZERO_IN_DATE：

[mysqld]
sql_mode = "ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

3. 保存文件后，重启MySQL服务：

sudo service mysql restart

这样以后所有新的MySQL会话都会使用这个宽松的SQL_MODE，再导入Dump就不会报错了。

方法3：修改Dump文件里的字段定义（最稳妥） #

你也可以直接修改SQL Dump文件中history表的date_time字段定义，把默认值改成合法的日期。比如：

• 如果希望默认值是当前时间，改成：

`date_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP

• 如果必须保留一个初始默认值，改成一个有效的日期，比如：

`date_time` datetime NOT NULL DEFAULT '1970-01-01 00:00:01'

修改后再导入Dump文件，不管SQL_MODE怎么设置都能正常执行。

补充说明 #

你本地的MySQL能正常运行，大概率是因为本地的SQL_MODE没有启用那些严格的日期校验规则——可能是本地MySQL版本低于5.7，或者你手动修改过SQL_MODE配置。

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