str_to_date()是mysql中可靠解析字符串为日期的专用函数，需配合明确格式模板使用，避免隐式转换错误；处理异常需用ifnull/coalesce，批量更新前须验证数据，注意版本差异与不可见字符清洗。
MySQL中用STR_TO_DATE()解析字符串为DATE
直接用 STR_TO_DATE()，它是MySQL专为字符串转日期设计的函数，比隐式转换可靠得多，也不会因区域设置或格式模糊导致意外结果。
常见错误是直接用 CAST('2023-05-12' AS DATE) 或 CONVERT(..., DATE)——它们在格式严格匹配时看似可行，但一旦字符串含多余空格、非标准分隔符（如“2023/05/12”或“12-May-2023”），就会返回 NULL 或静默截断成错误日期。
-
STR_TO_DATE()第二个参数必须是明确的格式模板，比如'%Y-%m-%d'对应'2023-05-12'，'%d/%m/%Y'对应'12/05/2023' - 月份缩写需用
'%b'（如'12-May-2023'→STR_TO_DATE('12-May-2023', '%d-%b-%Y')） - 如果输入可能为空或格式不一，务必配合
IFNULL()或COALESCE()防止NULL传播
处理带时间部分的字符串（DATETIME场景）
若原始字符串含时分秒（如 '2023-05-12 14:30:45'），仍用 STR_TO_DATE()，但格式模板要补全时间部分，否则只解析出日期、时间被丢弃。
例如：STR_TO_DATE('2023-05-12 14:30:45', '%Y-%m-%d %H:%i:%s') 返回 DATETIME 类型；若想转为纯 DATE，外层再套 DATE() 函数即可：
SELECT DATE(STR_TO_DATE('2023-05-12 14:30:45', '%Y-%m-%d %H:%i:%s'));
注意：%H 是24小时制，%h 是12小时制；%i 是分钟（不是 %m，那是月份）——写错格式符会导致整个解析失败并返回 NULL。
批量更新表中字符串列到DATE列时的坑
执行 UPDATE table SET date_col = STR_TO_DATE(str_col, '%Y-%m-%d'); 前，先验证格式一致性。MySQL不会报错，但解析失败的行会变成 NULL，且无提示。
- 用
SELECT str_col, STR_TO_DATE(str_col, '%Y-%m-%d') FROM table WHERE STR_TO_DATE(str_col, '%Y-%m-%d') IS NULL LIMIT 10;检查异常数据 - 避免在WHERE条件中直接用
STR_TO_DATE()做范围查询（如WHERE STR_TO_DATE(str_col, '%Y-%m-%d') > '2023-01-01'），它无法走索引，性能极差 - 生产环境建议先加临时
DATE列，填充后再原子化切换，防止中途出错影响主业务字段
不同MySQL版本对格式符的支持差异
MySQL 5.7+ 支持全部标准格式符，但早期版本（如5.6）对 %f（微秒）、%V（ISO周数）等支持不全。更隐蔽的问题是：MySQL 8.0.19起默认启用 sql_mode=STRICT_TRANS_TABLES，此时解析失败直接报错，而旧版本默认静默转为 0000-00-00 或 NULL。
检查当前模式：SELECT @@sql_mode;；若需兼容老行为，可临时设为 ''，但不推荐——掩盖问题不如提前清洗数据。
真正麻烦的不是语法，是那些看起来像日期却藏了不可见字符（比如BOM头、全角空格）的字符串，它们会让 STR_TO_DATE() 完全失效，得先用 TRIM() 和 REPLACE() 清洗。
