str_to_date静默返回null是mysql的设计选择，因其实行逐字符硬匹配，格式错位、非法日期或开头空格均导致失败，末尾空格可忽略；启用allow_invalid_dates会改变行为，但建议生产环境启用strict_trans_tables模式。
STR_TO_DATE 静默返回 NULL 是 MySQL 的默认行为
它不是 bug，是设计选择：MySQL 把 STR_TO_DATE() 定义为“尽力解析”，失败时不中断执行，而是返回 NULL。这跟 Oracle 的 TO_DATE() 或 PostgreSQL 的 TO_TIMESTAMP() 不同——后两者在格式不匹配或日期非法时会直接报错。
为什么格式错位、2 月 30 日、空格多一个都只返回 NULL？
因为 STR_TO_DATE() 的底层逻辑是「逐字符硬匹配」：从字符串开头开始，按格式符一个字符一个字符比对，中间任何不一致（比如该是 - 却遇到 /，该是两位月却只有一位数字，该是小写 mar 却写了大写 Mar）就立即终止并返回 NULL；末尾多余字符会被忽略，但开头错一点，全盘无效。
-
STR_TO_DATE('2023-2-30', '%Y-%m-%d')→NULL（2不是%m要求的两位数） -
STR_TO_DATE('2023-02-30', '%Y-%m-%d')→NULL（默认严格模式下，2 月 30 日非法） -
STR_TO_DATE(' 2023-02-15', '%Y-%m-%d')→NULL（开头空格不被跳过） -
STR_TO_DATE('2023-02-15 ', '%Y-%m-%d')→ ✅ 成功（末尾空格被忽略）
sql_mode 怎么悄悄改变 STR_TO_DATE 的行为？
关键开关是 ALLOW_INVALID_DATES。如果当前会话启用了它（常见于旧系统或兼容模式），STR_TO_DATE('2023-02-30', '%Y-%m-%d') 可能返回 '2023-02-30' 而不是 NULL——但这只是“存进去了”，后续做日期运算、比较、索引范围扫描时仍可能出错或失效。
- 查当前模式：
SELECT @@sql_mode; - 临时禁用宽松模式：
SET sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'; - 生产环境建议始终启用
STRICT_TRANS_TABLES，让非法解析尽早暴露
WHERE 条件里直接用 STR_TO_DATE 就等于放弃索引
比如写 WHERE STR_TO_DATE(log_date_str, '%Y/%m/%d') > '2024-01-01'，MySQL 必须对每行都执行一次函数计算，无法利用 log_date_str 字段上的索引——哪怕这个字段本身是 VARCHAR 且内容高度规律。更糟的是，你根本看不出慢，只看到结果为空或错乱。
- 正确做法：清洗阶段就用
STR_TO_DATE()转成新列（如parsed_date DATE），加索引，后续查询直接走该列 - 临时补救：先用
SELECT ... WHERE log_date_str REGEXP '^[0-9]{4}/[0-9]{2}/[0-9]{2}$'粗筛，再套STR_TO_DATE() - 别信“看起来像日期的字符串就能直接比较”——
'2023/1/5'和'2023/10/3'字符串比较结果是错的
IS NOT NULL，并在批量处理前用真实数据验证每种格式分支——尤其是当原始字段混着 API 返回、Excel 导入、用户手输多种来源时。
