STR_TO_DATE解析失败典型表现为返回NULL导致WHERE条件不成立，因格式需严格匹配；安全用法是将转换放值侧以利用索引；易与DATE_FORMAT（日期转字符串）混淆；推荐数据入库时清洗为标准日期类型。
STR_TO_DATE 解析字符串失败的典型表现
直接用 STR_TO_DATE 查日期却查不到记录？大概率是格式字符串没对上。MySQL 会严格按你写的格式去匹配输入字符串，哪怕多一个空格、少一个零，结果就是 NULL ——而 WHERE date_col = STR_TO_DATE(...) 在左边是 NULL 时永远不成立。
- 常见错误：把
'2023-5-1'当成'%Y-%m-%d'解析（实际该用'%Y-%c-%e'） - 更隐蔽的问题：前端传来的
'2023/05/01'被硬套'%Y-%m-%d'，斜杠不匹配直接返回NULL - 验证方法：先单独执行
SELECT STR_TO_DATE('2023/05/01', '%Y/%m/%d');看是否返回正确日期
WHERE 条件中用 STR_TO_DATE 的安全写法
别让 STR_TO_DATE 出现在字段一侧（比如 STR_TO_DATE(date_str, '%Y-%m-%d') = '2023-05-01'），这会导致索引失效，全表扫描。正确做法是把转换逻辑放在值侧，让字段保持原样参与索引查找。
- 如果
date_col是DATE或DATETIME类型：直接用WHERE date_col = '2023-05-01'，无需转换 - 如果
date_col是VARCHAR存的日期字符串：确保格式统一，再用WHERE date_col = '2023-05-01'（前提是字符串格式就是YYYY-MM-DD） - 真要解析字符串查：写成
WHERE date_col = STR_TO_DATE('2023/05/01', '%Y/%m/%d')，且确认date_col是日期类型；否则必须用STR_TO_DATE(date_col, ...)，但记得加函数索引（MySQL 8.0+）或改表结构
STR_TO_DATE 和 DATE_FORMAT 容易混淆的点
STR_TO_DATE 是「字符串 → 日期」，DATE_FORMAT 是「日期 → 字符串」，名字反着记的人不少。用错方向最直接的表现就是查询结果为空或类型报错。
-
STR_TO_DATE('01/05/2023', '%d/%m/%Y')→ 返回2023-05-01（日期类型） -
DATE_FORMAT('2023-05-01', '%d/%m/%Y')→ 返回'01/05/2023'（字符串） - 在
WHERE中误用DATE_FORMAT做条件转换，比如WHERE DATE_FORMAT(date_col, '%Y%m%d') = '20230501'，虽然能查，但无法走索引，性能差
替代 STR_TO_DATE 的更可靠方案
如果数据源不可控（比如 CSV 导入、日志解析），字符串格式五花八门，硬靠 STR_TO_DATE 逐个适配容易漏。优先考虑清洗阶段就转成标准日期类型存库，而不是每次查都现场解析。
- 导入时用
LOAD DATA INFILE配合SET col = STR_TO_DATE(@var, '%d.%m.%Y')直接转存 - 已有脏数据，用
ALTER TABLE ... ADD COLUMN date_real DATE+UPDATE ... SET date_real = STR_TO_DATE(date_str, ...)批量规整 - 实在要动态查，且格式杂：先用
CASE WHEN分支判断格式，再分别调用对应STR_TO_DATE，避免单个函数兜底失败
