str_to_date转换失败主因是格式符与字符串不匹配；须严格对应年份（%y/%y）、月份（%m/%c）、日期（%d/%e）及中文/特殊符号，注意空格、bom、am/pm等细节，并用trim、regexp、coalesce等辅助处理。
STR_TO_DATE函数的基本用法和常见失败原因
直接用 STR_TO_DATE 转换字符串失败，大概率不是函数写错了，而是格式符和输入字符串对不上。MySQL 会严格按格式符逐字符匹配，多一个空格、少一个分隔符、年份用两位而写了%Y，都会返回 NULL。
比如把 '2023-05-12' 传给 STR_TO_DATE('2023-05-12', '%y-%m-%d') 就会失败——%y 只认两位年份（如 '23'），而 %Y 才对应四位。
- 始终用
%Y匹配四位年份，%y匹配两位年份 - 月份用
%m（补零数字，如'05'），不用%c（不补零，如'5'），除非你确定源数据没补零 - 日期部分同理：
%d（'07'） vs%e（'7'） - 中文或全角符号（如“年”“月”“日”、全角短横）必须原样写进格式串，且注意编码一致
处理带中文、非标准分隔符的日期字符串
从 Excel 导出或用户输入的日期常含中文，例如 '2023年05月12日' 或 '2023/05/12'。这时格式串不能硬套 '%Y-%m-%d'，得一字不差地对齐。
示例：
SELECT STR_TO_DATE('2023年05月12日', '%Y年%m月%d日'); -- 正确
SELECT STR_TO_DATE('2023/05/12', '%Y/%m/%d'); -- 正确
SELECT STR_TO_DATE('2023-05-12 14:30:00', '%Y-%m-%d %H:%i:%s'); -- 注意时分秒用 %H %i %s
-
%i是分钟（不是%m，那是月份），%s是秒，%H是24小时制小时 - 如果字符串里有“下午 2:30”，得先用
REPLACE处理，STR_TO_DATE本身不识别 AM/PM - 字段值含不可见字符（如 Excel 导出带 BOM 或尾部空格）？先用
TRIM()清理再转换
在 INSERT 或 UPDATE 中安全使用 STR_TO_DATE
直接把 STR_TO_DATE 塞进 INSERT 语句，一旦某条记录格式异常，整条语句可能因类型不匹配被拒绝（尤其目标列为 DATE 非空且无默认值时）。
- 先用
SELECT测试转换结果：SELECT col, STR_TO_DATE(col, '%Y-%m-%d') FROM tbl WHERE ...，确认 NULL 比例 - 配合
COALESCE提供兜底：COALESCE(STR_TO_DATE(date_str, '%Y-%m-%d'), '1970-01-01') - 目标列为
DATETIME但源只有日期？补上固定时间：STR_TO_DATE(date_str, '%Y-%m-%d') + INTERVAL 0 SECOND（自动转为DATETIME类型） - 避免在 WHERE 条件中对大表字段用
STR_TO_DATE，无法走索引，性能极差
STR_TO_DATE 返回 NULL 却没报错，怎么定位问题
MySQL 默认不会因 STR_TO_DATE 失败报错，只静默返回 NULL，容易掩盖数据质量问题。
- 开启严格模式（
STRICT_TRANS_TABLES）能让部分隐式转换报错，但STR_TO_DATE本身仍返回 NULL - 主动检查：加条件
WHERE STR_TO_DATE(col, '%Y-%m-%d') IS NULL AND col != ''找出坏数据 - 用正则预筛：
col REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2}$'排除明显不合格式的值，再进STR_TO_DATE - 注意时区影响：函数本身不涉及时区，但如果后续参与
NOW()或CONVERT_TZ计算，时间值已按系统时区解释
真正麻烦的是混合格式——同一列里有 '2023-05-12'、'12/05/2023'、'20230512'。这种没法靠单个 STR_TO_DATE 解决，得用嵌套 CASE WHEN 分流处理，逻辑立刻变重。
