STR_TO_DATE本身不报Warning，仅静默返回NULL；Warning实际源于后续插入、隐式转换或sql_mode设置（如ALLOW_INVALID_DATES）等环节。
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'（虽然逻辑错误），关了它就直接报错中断。
