mysql报错1067是什么原因_mysql配置错误排查

mysql 错误 1067 是 sql 层面报错，主因是 not null 的 datetime/timestamp 字段设 default null 或使用 ’0000-00-00’ 等零日期；5.7+ 默认严格模式（strict_trans_tables）加强校验，需改默认值为 current_timestamp 或调整 sql mode。

MySQL 错误 1067：Invalid default value for ‘xxx’

这个错误不是服务启动失败的系统级报错（那是 Windows 服务 1067），而是执行 CREATE TABLE 或 ALTER TABLE 时触发的 SQL 层面报错，核心原因是字段默认值不合法——最常见的是给 NOT NULL 的 DATETIME 或 TIMESTAMP 字段设了 DEFAULT NULL，或者用了已废弃的零日期（如 '0000-00-00'）。

为什么严格模式下会报 1067，而旧版本不报？

MySQL 5.7+ 默认启用严格 SQL 模式（STRICT_TRANS_TABLES），此时对默认值校验变严。关键点：

• TIMESTAMP 字段若声明 NOT NULL，却指定 DEFAULT NULL → 直接报 1067
• DATETIME 在 5.7.5+ 不再隐式接受 '0000-00-00' 作为默认值，除非显式关闭 NO_ZERO_DATE
• 即使字段允许 NULL，DEFAULT '0000-00-00 00:00:00' 也会被拒绝（除非 SQL mode 中移除了 NO_ZERO_DATE）

快速修复：改默认值 or 调整 SQL mode

优先推荐改表结构，避免依赖宽松模式：

• 把 DEFAULT NULL 改成有效时间，例如：DEFAULT CURRENT_TIMESTAMP（TIMESTAMP/5.6.5+ DATETIME 支持）
• 把 NOT NULL 去掉，如果业务允许该字段为空
• 用 CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 替代固定零值
• 临时绕过（不推荐生产）：启动时加参数 --sql-mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION" 并去掉 NO_ZERO_DATE，但会掩盖数据质量问题

检查当前 SQL mode 和日期行为

运行这条语句确认实际生效的模式：

SELECT @@sql_mode;

重点关注是否含 STRICT_TRANS_TABLES、NO_ZERO_DATE、NO_ZERO_IN_DATE。再查零日期是否被禁用：

SELECT @@sql_mode LIKE '%NO_ZERO_DATE%';

如果返回 1，说明零日期已被禁止——这时任何含 '0000-00-00' 的默认值都会触发 1067。迁移老表时最容易漏掉这点，尤其从 5.6 升级到 8.0 后。