STR_TO_DATE() 严格按指定格式解析日期字符串，格式不匹配则静默返回NULL而非报错；需注意格式符位数要求、预处理数据、避免全表函数计算及合理使用生成列索引。
MySQL 中 STR_TO_DATE() 的基本用法
它不是万能格式转换器，而是严格按指定格式解析字符串——格式不对，结果就是 NULL，且不报错。比如 '2023-10-05' 不能直接用 %Y-%m-%d 以外的格式去套，否则返回空。
-
STR_TO_DATE('2023/10/05', '%Y/%m/%d')→ 正确返回2023-10-05 -
STR_TO_DATE('2023-10-05', '%Y/%m/%d')→ 返回NULL（斜杠和短横不匹配） - 常见格式符：
%Y（4位年）、%y（2位年）、%m（01–12）、%c（1–12，无前导零）、%d（01–31）、%e（1–31）
为什么 STR_TO_DATE() 返回 NULL 却没报错
MySQL 默认开启宽松模式，遇到无法解析的字符串就静默返回 NULL，而不是中断或抛异常。这在调试时极容易被忽略——你以为数据进去了，其实全是空值。
- 先确认输入字符串是否干净：用
TRIM()去掉首尾空格，用REGEXP '^[0-9/\-\. ]+$'粗筛非法字符 - 临时加个判断辅助排查：
SELECT str_col, STR_TO_DATE(str_col, '%Y-%m-%d') AS parsed, ISNULL(STR_TO_DATE(str_col, '%Y-%m-%d')) AS is_null FROM tbl WHERE ... - 开启严格 SQL 模式（如
STRICT_TRANS_TABLES）也不能让STR_TO_DATE()报错，它天生就只返回NULL
从 CSV 或日志导入时日期格式混乱怎么办
现实数据常混着多种格式：'05/Oct/2023'、'20231005'、'5-Oct-2023'。一个 STR_TO_DATE() 调用搞不定，得靠条件判断兜底。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 用
CASE WHEN分流处理：CASE WHEN str_col REGEXP '^[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}$' THEN STR_TO_DATE(str_col, '%Y/%c/%e') ... END - 注意
%c和%e才支持无前导零的月/日，%m/%d强制要求两位，否则失败 - 如果原始字段是
VARCHAR(10)却存了'2023-10-05 14:30:00'，先用SUBSTRING(str_col, 1, 10)截断，否则整个解析失败
性能与索引注意事项
STR_TO_DATE() 是计算字段，无法走索引。如果经常按解析后的日期查询，别在 WHERE 里现场转换。
- 建表时就加生成列：
parsed_date DATE AS (STR_TO_DATE(raw_str, '%Y-%m-%d')) STORED，再给它加索引 - 避免在大表上写
UPDATE t SET date_col = STR_TO_DATE(str_col, '%Y%m%d') WHERE ...—— 没索引条件时全表扫描+函数计算，慢到卡死 - 批量导入前，用客户端（如 Python +
datetime.strptime）预处理好日期，比在 MySQL 里用STR_TO_DATE()快得多
最常被忽略的是格式符和实际字符串的“位数一致性”：比如 %m 要求两位月份数字，但你传了 '2023-1-5'，就得换 %c 和 %e。这种细节不验证，数据就悄悄变 NULL。
