STR_TO_DATE在MySQL 5.7中仅能解析格式明确、逐字符匹配的字符串，如'2023-12-05T14:30:00'、'Dec 5, 2023'等；对模糊语义（如'约2023年底'）、大小写/空格/标点不一致、中文环境匹配英文缩写等情形均静默返回NULL。
STR_TO_DATE在MySQL 5.7里能解析哪些不规则格式
STR_TO_DATE不是万能时间清洗工具，它只接受明确、可映射的格式字符串。比如 '2023-12-05T14:30:00'（ISO 8601带T）、'Dec 5, 2023'、'05/Dec/2023' 这类有固定分隔和顺序的字符串才能被正确识别；但像 '约2023年底'、'上个月15号左右' 这种含模糊语义或缺失字段的，MySQL 5.7 会直接返回 NULL，且不报错——这是最容易忽略的陷阱。
关键点在于：格式符必须与输入字符串**逐字符对齐**，空格、标点、大小写都算在内。例如 '%d-%b-%Y' 能匹配 '05-Dec-2023'，但匹配不了 '5-Dec-2023'（日为单数字）或 '05-DEC-2023'（月份大写，而 %b 默认小写缩写）。
常见错误：时区、语言环境和格式符不一致
MySQL 5.7 的 STR_TO_DATE 默认使用服务器的 lc_time_names 设置，中文环境下 %b 可能匹配不到 'Dec'，反而期待 '12月'。如果你的原始数据是英文月份但数据库是 zh_CN，函数会静默失败。
- 查当前设置：
SELECT @@lc_time_names; - 临时切英文：
SET lc_time_names = 'en_US';（仅当前会话有效） - 避免依赖本地化：用数字代替月份缩写，如把
'Dec 5, 2023'改成'12/05/2023'，再用'%m/%d/%Y' - 注意年份占位：
%y解析两位数年（如'23'→2023），%Y必须四位；混用会导致NULL
处理含多余空格或混合分隔符的实际数据
真实日志或爬虫数据常有空格不一、中英文标点混用问题，比如 '2023年12月 05日 ' 或 '2023/12'。STR_TO_DATE 不做预清洗，必须先用 REPLACE 或 TRIM 规范化：
SELECT STR_TO_DATE(
TRIM(REPLACE(REPLACE('2023年12月 05日 ', '年', '-'), '月', '-')),
'%Y-%m-%d'
);
注意：嵌套太多会影响性能，尤其在 WHERE 条件中使用时会强制全表扫描（无法走索引）。建议在 ETL 阶段就清洗好，而非查询时实时转换。
另一个坑是反斜杠转义：如果原始字符串含 （如 Windows 路径风格时间 '2023
'），MySQL 会把它当转义符处理，需用双反斜杠 '2023\12\05' 或改用正则替换（MySQL 5.7 不支持 REGEXP_REPLACE，只能靠多层 REPLACE）。
替代方案：当STR_TO_DATE彻底失效时怎么办
遇到真正不规则的格式（如 '第3季度2023'、'2023Q3'、'2023-W49'），STR_TO_DATE 无解。这时得靠字符串函数组合硬解：
-
SUBSTRING_INDEX拆字段：SUBSTRING_INDEX('2023Q3', 'Q', -1)→'3' -
CONCAT拼标准格式：CONCAT('2023-', LPAD(3*CAST(SUBSTRING_INDEX('2023Q3','Q',-1) AS SIGNED),2,'0'), '-01')→'2023-09-01' - 用
CASE WHEN映射季度：CASE SUBSTRING_INDEX(col, 'Q', -1) WHEN '1' THEN '04-01' ... END
这种逻辑复杂、可读性差，且无法利用时间索引。真正要长期维护，不如在应用层或前置ETL中统一归一化，别让 MySQL 5.7 承担本不属于它的文本解析职责。
最常被忽视的一点：STR_TO_DATE 返回的是 DATETIME 类型，但如果输入字符串只有日期（如 '2023-12-05'），结果是 '2023-12-05 00:00:00' —— 看似没问题，但后续做日期范围查询时，容易因隐式类型转换漏掉当天的非零时分数据。
