根本原因是MySQL在语义层面主动拦截非法日期值，如零日期'0000-00-00'或超范围值，而非单纯格式错误；MySQL 5.7.8+默认启用NO_ZERO_DATE和NO_ZERO_IN_DATE模式，导致插入此类值直接报ERROR 1292。
MySQL报Incorrect datetime value的根本原因
这不是格式写错那么简单——而是MySQL在语义层面对日期值做了主动拦截。只要值落在'1000-01-01 00:00:00'到'9999-12-31 23:59:59'范围外，或违反日历逻辑（比如'0000-00-00'、'2023-02-30'），就会直接拒绝，哪怕字段类型是DATETIME。
最常踩的坑：零日期被默认拦截
MySQL 5.7.8+ 默认启用NO_ZERO_DATE和NO_ZERO_IN_DATE，导致插入'0000-00-00'或'0000-00-00 00:00:00'直接报ERROR 1292。这不是BUG，是设计行为。
- 临时绕过：执行
SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';（仅当前会话有效） - 永久生效：必须编辑
my.cnf或my.ini，在[mysqld]下写入sql_mode=STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION，然后重启服务 -
ALLOW_INVALID_DATES不能解决零日期问题——它只对DATETIME生效，且不放行'0000-00-00'，仅放宽如'2023-02-30'这类非法日
其他高频触发场景
除了零日期，这些也常被忽略：
- 字段是
TIMESTAMP却插了'0000-00-00 00:00:00'——TIMESTAMP范围是'1970-01-01 00:00:01'到'2038-01-19 03:14:07'，超出就报错 - 用
STR_TO_DATE()时格式串不匹配，比如STR_TO_DATE('2023/01/01', '%Y-%m-%d')会失败，因为分隔符是/而非- - ORM或Excel导出数据时自动补空字符串
''或null进NOT NULL的DATETIME字段，MySQL不接受空字符串作为日期 - JDBC驱动版本过高（如8.0+）默认开启严格模式，应用层没传
serverTimezone或useLegacyDatetimeCode=false，也可能触发校验
真正要检查的三件事
别急着改sql_mode，先确认：
- 查字段定义：
SHOW CREATE TABLE table_name;看类型是DATETIME、TIMESTAMP还是DATE，对应范围不同 - 查当前模式：
SELECT @@sql_mode;确认是否含NO_ZERO_DATE等项 - 查原始值来源：是硬编码SQL？ORM生成？Excel导入？还是前端传参？空值、非法字符、时区转换错误往往藏在这里
改配置能压住报错，但掩盖不了数据语义缺陷——零日期到底代表“未知”还是“无效”，得由业务定，数据库只是执行者。
