MySQL报Incorrect datetime value的直接原因是严格模式拒绝不合规字符串，只认'YYYY-MM-DD HH:MM:SS'标准格式，且须字段类型匹配、插入值规范、sql_mode不含STRICT_TRANS_TABLES；推荐用STR_TO_DATE清洗不可控输入。
MySQL报Incorrect datetime value的直接原因
不是你写错了，而是MySQL在严格模式下拒绝解析不合规的字符串。它只认'YYYY-MM-DD HH:MM:SS'（注意是MM分钟、HH小时），且年月日时分秒必须全齐、分隔符必须一致、不能多空格、不能含中文或全角符号。
INSERT前必须验证的三件事
别急着改SQL，先确认这三项：
- 目标字段类型是
DATETIME还是TIMESTAMP？两者都要求标准格式，但TIMESTAMP还受时区和0000-00-00 00:00:00限制 - 插入值是硬编码字符串（如
'2026-08-11 03:00:00'）还是程序拼接？后者极易带空格、换行或BOM头 - MySQL当前
sql_mode是否含STRICT_TRANS_TABLES？查SELECT @@sql_mode，若含此项，非法值直接报错；不含则可能转成0000-00-00 00:00:00并警告
安全写法：用STR_TO_DATE替代硬拼字符串
前端或代码传来的日期字符串格式不可控（比如'2026/08/11'、'11-08-2026'、'20260811'），硬改应用层成本高。直接在SQL里清洗：
INSERT INTO events (start_time) VALUES (STR_TO_DATE('2026/08/11', '%Y/%m/%d'));
关键点：
-
STR_TO_DATE()第一个参数是原始字符串，第二个是对应格式模型，顺序不能反 - 格式模型中
%m是月份（01–12），%i才是分钟（00–59）——写成%mm或%mi会静默失败 - 如果字符串可能为空或非法，加
WHERE过滤：WHERE 'input_str' REGEXP '^[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}$'
Oracle里ORA-01861的典型陷阱
错误常出现在TO_DATE()调用中，不是格式不对，而是你没意识到它对输入极其苛刻：
- 字符串里有隐藏空格？用
TRIM()包一层：TO_DATE(TRIM(:date_str), 'YYYY-MM-DD HH24:MI:SS') - 格式串里的
-、/、空格必须和字符串里完全一致——'2026-08-11'配'YYYY/MM/DD'必报错 - 别把
sysdate或JavaDate对象再塞给TO_DATE()，它只吃字符串；MyBatis传#{date}时，JDBC已自动处理，SQL里直接写sc.ZPSJ >= #{startDate}就行
最易被忽略的是NLS设置差异：开发库NLS_DATE_FORMAT='YYYY-MM-DD'能过，生产库设成DD-MON-RR就崩——永远显式指定格式，别依赖会话变量。
