使用ALTER TABLE语句更改列的默认值，例如:

 ALTER TABLE users MODIFY created datetime  NULL DEFAULT '1970-01-02'

．.． 不会改变已经存储的任何值。“默认”值应用于插入的行，并且没有为列提供值。

至于为什么会遇到这个错误，可能是因为会话的sql_mode设置包含了NO_ZERO_DATE。

参考:http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html # sqlmode_no_zero_date

当您执行“导入”操作时，执行INSERT操作的SQL语句将在允许零日期的会话中运行。

查看sql_mode设置:

SHOW VARIABLES LIKE 'sql_mode' ;

-or-

SELECT @@sql_mode ;

至于如何“修复”当前的问题，以便在运行ALTER TABLE语句时不会抛出错误。

几个选项:

1)通过删除NO_ZERO_DATE和NO_ZERO_IN_DATE，将sql_mode更改为允许零日期。更改可以应用在my.cnf文件中，因此在MySQL服务器重新启动后，sql_mode变量将被初始化为my.cnf中的设置。

对于临时更改，我们可以使用单个会话修改设置，而不需要全局更改。

-- save current setting of sql_mode
SET @old_sql_mode := @@sql_mode ;

-- derive a new value by removing NO_ZERO_DATE and NO_ZERO_IN_DATE
SET @new_sql_mode := @old_sql_mode ;
SET @new_sql_mode := TRIM(BOTH ',' FROM REPLACE(CONCAT(',',@new_sql_mode,','),',NO_ZERO_DATE,'  ,','));
SET @new_sql_mode := TRIM(BOTH ',' FROM REPLACE(CONCAT(',',@new_sql_mode,','),',NO_ZERO_IN_DATE,',','));
SET @@sql_mode := @new_sql_mode ;

-- perform the operation that errors due to "zero dates"

-- when we are done with required operations, we can revert back
-- to the original sql_mode setting, from the value we saved
SET @@sql_mode := @old_sql_mode ;

2)将创建的列更改为允许空值，并更新现有行以将零日期更改为空值

3)更新现有行，将零日期更改为有效日期

我们不需要运行单独的语句来更新每一行。我们可以一口气更新所有的行(假设它是一个合理大小的表。对于一个较大的表，为了避免产生大量的回滚/撤销，我们可以在合理大小的块中执行操作。)

在这个问题中，表定义中显示的AUTO_INCREMENT值向我们保证行数不会过多。

如果我们已经修改了创建的列以允许NULL值，我们可以这样做:

UPDATE  `users` SET `created` = NULL WHERE `created` = '0000-00-00 00:00:00'

或者，我们可以将它们设置为一个有效的日期，例如1970年1月2日

UPDATE  `users` SET `created` = '1970-01-02' WHERE `created` = '0000-00-00 00:00:00'

(注意，datetime值为1970年1月1日午夜('1970-01-01 00:00:00')是一个“零日期”。它将被计算为'0000-00-00 00:00:00'

对于Symfony用户:添加一个默认的orm列，如下所示:

/**
 * @var DateTime $updatedAt
 *
 * @ORM\Column(name="updated_at", type="datetime", nullable=false, options={"default" : "CURRENT_TIMESTAMP"})
 */

下面是我的解决方案PhpMyAdmin / Fedora 29 / MySQL 8.0(以)为例:

设置sql_mode = '东西';不工作，命令调用成功，但什么都没有改变。

set GLOBAL sql_mode='SOMETHING';更改全局配置永久更改。

set SESSION sql_mode='SOMETHING';session变量只影响当前客户端。

https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html

所以我这样做:

显示类似SQL_MODE的变量; 结果: ONLY_FULL_GROUP_BY、STRICT_TRANS_TABLES NO_ZERO_IN_DATE、NO_ZERO_DATE ERROR_FOR_DIVISION_BY_ZERO NO_ENGINE_SUBSTITUTION 删除结果:NO_ZERO_IN_DATE,NO_ZERO_DATE 设置新的配置:Set GLOBAL SQL_MODE='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'

您可以以同样的方式删除或添加其他模式。

这有助于更改使用和测试框架的全局或sql_mode必须在每个文件或一组查询中指定。

改编自这里的一个问题:how-can-i-disable-mysql-strict-mode

示例:安装最新的Joomla 4.0 alpha内容。

编辑: 在PhpMyadmin中，如果您拥有服务器的控制权，您可以直接在Plus > Variables > sql_mode中更改sql_mode(以及所有其他参数)

这是非常丑陋的，但它也很快为我解决了问题。您的表需要一个唯一的键，您将使用它来修复受污染的列。在这个例子中，主键被称为“id”，损坏的时间戳列被称为“BadColumn”。

选择受污染列的id。 select id from BadColumn='0000-00-00 00:00:00' 将id收集到一个以逗号分隔的字符串中。例如:1,22,33。为此，我使用了一个外部包装器(Perl脚本)来快速地将它们全部输出。 使用id列表使用有效日期(1971年到2038年)更新旧列。 更新表BadColumn='2000-01-01 00:00:00' where id in (1,22,33)

出现这个问题是因为MYSQL 5.7引入了默认模式，比如

SELECT @@GLOBAL.sql_mode global, @@SESSION.sql_mode session;
=> ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

在默认模式中，有一个模式NO_ZERO_DATE阻止您在datetime列中放置值0000-00-00 00:00:00。

临时修复将从默认模式中删除模式NO_ZERO_DATE/NO_ZERO_IN_DATE，并保持其他模式不变。

SET GLOBAL sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

但是一旦你重新启动你的mysql服务器，你所有的临时设置将消失，默认模式将再次启用。要在重新启动时修复此问题，请更改计算机上my.cnf文件中的默认模式。

参考文档:- https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#:~:text=To%20set%20the%20SQL%20mode,ini%20(Windows)。

我个人的观点:-正确的开发实践应该是在列中放入正确的datetime值，而不是0000-00-00 00:00:00。这样你就不用担心SQL模式了。

您可以将创建的字段的类型从datetime更改为varchar(255)，然后您可以将(更新)所有值为“0000-00-00 00:00:00”的记录设置为NULL。

现在，您可以无错误地执行查询。 完成后，您可以更改创建为datetime的字段类型。