STR_TO_DATE 为什么总返回 NULL？

STR_TO_DATE 返回 NULL 的根本原因不是函数坏了，而是格式字符串和输入字符串不严格匹配。MySQL 会逐字符比对，哪怕多一个空格、少一个分隔符、年份位数不对（比如用 %Y 解析 "21"），都会失败。

常见错误现象：STR_TO_DATE('2023-1-5', '%Y-%m-%d') 返回 NULL（因为 %m 和 %d 要求两位，而输入只有一位）；STR_TO_DATE('2023/1/5', '%Y-%m-%d') 也返回 NULL（格式完全错位，分隔符不一致）。

• 必须确保输入字符串中每个非字面量部分（如数字、斜杠）都与格式符一一对应，任何额外的字符都会导致解析失败。
• 月份、日期不足两位时，不能强制用 %m 或 %d —— 改用 %c（1–12）或 %e（1–31），它们允许单数月份或日期。
• 年份要分清：%y 是两位（00–99），%Y 是四位；解析 "23" 必须用 %y，否则失败。

处理带中文或混合符号的日期字符串

比如 '2023年1月5日'、'Jan 5, 2023' 这类非标准字符串，不能靠改格式符硬套，得先清洗或拆分。

STR_TO_DATE 本身不支持正则替换，所以得组合使用函数：

处理非标准日期字符串的关键细节

在使用 STR_TO_DATE 转换非标准日期时，需特别注意格式符的精确匹配与预处理。首先，利用 REPLACE() 去除中文单位可简化解析过程，例如执行 STR_TO_DATE(REPLACE(REPLACE(REPLACE('2024年05月01日', '年', '-'), '月', '-'), '日', ''), '%Y-%m-%d') 以清理冗余字符。其次，当字符串包含时间且带有“上午”或“下午”标识时，直接转换可能不够安全。建议采用 REPLACE(REPLACE('2024/5/1 上午10:30', '上午', ''), '下午', '12') 进行初步处理，并结合 CASE 与 SUBSTRING 进行逻辑判断，必要时手动添加时间偏移量以确保准确性。此外，STR_TO_DATE 对时间部分极为敏感，必须严格区分 %H（范围 00–23）与 %h（范围 01–12），二者不可混用。只有搭配 %p 格式符，数据库才能正确识别并解析 AM/PM 标识，避免解析错误。

在 INSERT 或 UPDATE 中安全使用 STR_TO_DATE

直接将 STR_TO_DATE() 嵌入 INSERT 语句存在风险。若某条记录格式异常，整条语句可能因类型转换失败而报错，尤其在开启严格模式的数据库环境中更为常见。为确保数据写入的安全性，建议采取以下措施：

• 先使用 SELECT STR_TO_DATE(...) 对一批样本数据进行单独测试，确认无 NULL 后再执行批量写入操作。
• 在插入前增加判断逻辑：IFNULL(STR_TO_DATE(@raw_date, '%Y/%c/%e'), '0000-00-00')，以避免异常数据阻断整个流程。但需注意，'0000-00-00' 这种特殊值在严格模式下也可能被拒绝，需根据业务需求调整。
• 若源数据来自 CSV 文件或系统日志，建议在加载前使用脚本将其预处理为统一格式，而非完全依赖 SQL 转换。STR_TO_DATE 并非万能的数据清洗工具，预处理能显著提升效率与稳定性。

替代方案：什么时候该放弃 STR_TO_DATE？

当遇到以下情况时，硬套 STR_TO_DATE 往往效率低下且维护困难，不如转换思路：

常见陷阱与注意事项

• 同一字段混杂多种格式（如有的写 "2024-01-01"，有的写 "01/01/2024"，还有的写 "Jan 1, 2024"）—— 此时应拆成多个 CASE WHEN 分支，各自配格式符
• 需要毫秒级精度或时区信息 —— STR_TO_DATE 不支持 %f（微秒）以外的精度，也不解析时区缩写（如 "CST"），这类需求得靠应用层处理
• MySQL 版本 < 5.7 且启用了 NO_ZERO_DATE 模式时，STR_TO_DATE('abc', ...) 可能触发警告甚至中断，比预期更脆弱

真正麻烦的从来不是函数怎么写，而是原始数据到底有多“脏”——格式不一致、缺失字段、非法字符、编码乱码，这些都得在调用 STR_TO_DATE 前搞定。