为什么MySQL中STR_TO_DATE转换日期格式会报Warning-mysql教程-PHP中文网

STR_TO_DATE本身不报Warning，仅静默返回NULL；Warning实际源于后续插入、隐式转换或sql_mode设置（如ALLOW_INVALID_DATES）等环节。

为什么mysql中str_to_date转换日期格式会报warning

STR_TO_DATE() 本身不报 Warning，报 Warning 的是后续隐式转换或插入行为

你执行 STR_TO_DATE('2023-02-30', '%Y-%m-%d') 不会触发 Warning，它只安静返回 NULL。真正让你看到 Warning 的，通常是下面这些场景：

把 STR_TO_DATE() 结果直接插进 DATE 或 DATETIME 字段，而该字段不允许 NULL，且没开启严格模式 → MySQL 自动转成 '0000-00-00'，并抛出 Incorrect date value: '0000-00-00' 类 Warning
在 INSERT ... SELECT 或 LOAD DATA INFILE 中，STR_TO_DATE() 返回 NULL，但目标列设了 NOT NULL DEFAULT CURRENT_TIMESTAMP → 某些版本会警告“Data truncated for column”
传入字符串含不可见字符（如 BOM、\r、全角空格），STR_TO_DATE() 解析失败返回 NULL，后续用 COALESCE(..., '1970-01-01') 补默认值时，类型不一致触发隐式转换 Warning

为什么 Warning 常被忽略？

MySQL 默认的 sql_mode 往往不含 STRICT_TRANS_TABLES，导致非法日期不报错，只发 Warning；而客户端（比如 MySQL CLI、PHP mysqli）默认不显示 Warning，除非你显式调用 SHOW WARNINGS。

常见诱因包括：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

STR_TO_DATE('2023-02-30', '%Y-%m-%d') → 合法输入但语义非法，返回 NULL，不 Warning
STR_TO_DATE('2023/02/30', '%Y-%m-%d') → 格式错位，返回 NULL，也不 Warning
但一旦你写：INSERT INTO t(dt) VALUES (STR_TO_DATE('2023-02-30', '%Y-%m-%d'))，且 t.dt 是 NOT NULL DATE，MySQL 就可能存 '0000-00-00' 并记一条 Warning

如何确认是不是 STR_TO_DATE 导致的 Warning

别猜，直接查：

SELECT STR_TO_DATE('2023-02-30', '%Y-%m-%d') AS result;
SHOW WARNINGS;

如果 result 是 NULL 且 SHOW WARNINGS 为空，说明 STR_TO_DATE 没问题；Warning 一定来自后续环节。

真正要盯紧的，不是函数本身报什么，而是你把它塞进哪、字段定义是什么、当前 sql_mode 开了哪些开关——尤其是 ALLOW_INVALID_DATES 这个选项，开了它连 '2023-02-30' 都能硬转成 '2023-02-30'（虽然逻辑错误），关了它就直接报错中断。