str_to_date()需严格匹配字符串与格式模板，错配静默返回null；支持无分隔符格式如'%y%m%d'，但%c/%e用于无前导零月/日，%y/%y须与年份位数一致，中文或混合符号需预清洗，性能敏感场景应使用生成列+索引。
MySQL里用STR_TO_DATE()转换字符串为日期
直接用 STR_TO_DATE()，别用 CAST() 或 CONVERT() —— 它们对非标准格式的字符串基本无效，容易返回 NULL 或静默截断。
这个函数需要两个参数：待转换的字符串和对应的格式模板。模板必须严格匹配字符串内容，差一个空格或字母大小写都会失败。
-
STR_TO_DATE('2023-05-12', '%Y-%m-%d')✅ 返回2023-05-12 -
STR_TO_DATE('12/05/2023', '%d/%m/%Y')✅ 注意顺序，不是'%m/%d/%Y' -
STR_TO_DATE('20230512', '%Y%m%d')✅ 没分隔符也支持 -
STR_TO_DATE('2023-05-12 14:30:00', '%Y-%m-%d %H:%i:%s')✅ 时间部分用%H（24小时制），别错写成%h（12小时制）
常见错误：格式符写错导致全返回NULL
MySQL 不报错，只默默返回 NULL，查不到数据时很难发现是这里出问题。比如把英文月份写成 '%M' 却传入中文字符串 '五月'，结果就是 NULL；又或者用 '%y'（两位年份）去解析 '2023'，也会失败。
- 月份名：英文用
%M（如'May'），数字用%m（如'05'） - 小时：24小时制用
%H，12小时制用%h，且后者必须搭配%p（'AM'/'PM'） - 星期：
%W是完整英文名（'Monday'），%w是数字（1表示周一，0表示周日） - 不确定格式时，先用
SELECT STR_TO_DATE(...)单独测试，别直接写进UPDATE或WHERE
批量更新时怎么避免脏数据写入
如果字段原本是 VARCHAR，现在想转成 DATE 类型，不能直接 ALTER TABLE ... MODIFY COLUMN —— MySQL 会尝试隐式转换，失败就填 '0000-00-00'，这在严格模式下甚至会报错。
- 先加一个新列：
ALTER TABLE t ADD COLUMN dt DATE - 用
STR_TO_DATE()填值，配合WHERE过滤掉无法转换的行：UPDATE t SET dt = STR_TO_DATE(date_str, '%Y-%m-%d') WHERE date_str REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2}$' - 检查
dt是否有NULL：SELECT * FROM t WHERE dt IS NULL AND date_str != ''，人工核对异常格式 - 确认无误后再删旧列、重命名新列
时区和系统变量会影响结果吗
不影响 STR_TO_DATE() 的解析逻辑 —— 它纯按字符串和格式模板做文本匹配，不涉及时区转换。但后续用这个日期参与计算（比如 DATE_ADD(dt, INTERVAL 1 DAY)）或存入 DATETIME 字段时，才可能受 time_zone 设置影响。
-
SELECT @@time_zone查当前会话时区，一般不影响转换本身 - 如果源字符串带时区信息（如
'2023-05-12T14:30:00+08:00'），STR_TO_DATE()无法识别，得先用字符串函数剥离时区部分 - 真正要处理带时区的时间戳，应该用
FROM_UNIXTIME(UNIX_TIMESTAMP(...))配合时区转换，而不是硬套STR_TO_DATE()
实际执行前，务必用真实数据样本跑一遍 STR_TO_DATE()，尤其注意空格、中英文标点、大小写、年份位数这些肉眼容易忽略的差异。
