STR_TO_DATE用于将字符串按指定格式解析为DATE或DATETIME类型，需严格匹配预定义格式符（如%Y、%m、%d），解析失败默认返回NULL而非报错，使用时应避免在WHERE中直接调用以防索引失效。
STR_TO_DATE 用法和常见格式字符串写法
STR_TO_DATE 的核心作用是把字符串按指定格式解析成 MySQL 的 DATETIME 或 DATE 类型。它不是“格式化输出”，而是“反向解析”——这点容易搞反。比如 '2024-03-15' 是标准格式，直接转 DATE 不需要它；但 '15/03/2024' 或 'Mar 15, 2024' 就必须靠 STR_TO_DATE 才能入库。
关键在第二个参数：格式模型字符串。它不是正则，也不是任意写，必须用 MySQL 预定义的格式符，比如：
-
%Y表示 4 位年份（2024），%y是 2 位（24） -
%m是 01–12 的月份数字，%c是 1–12（不补零） -
%d是 01–31 的日期，%e是 1–31 -
%M是英文全称（March），%b是缩写（Mar）
错误示例：STR_TO_DATE('2024-03-15', '%Y-%m-%d') 能成功，但 STR_TO_DATE('2024-03-15', '%Y/%m/%d') 返回 NULL，因为斜杠不匹配。
为什么 STR_TO_DATE 返回 NULL 而不是报错
MySQL 默认对 STR_TO_DATE 的解析失败不抛异常，而是静默返回 NULL。这会让问题很难被发现，尤其在 INSERT 或 UPDATE 中导致字段被设为 NULL 或触发默认值逻辑。
排查方法很简单：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先单独执行
SELECT STR_TO_DATE('你的字符串', '你的格式');看是否返回NULL - 检查字符串中是否有不可见字符（如 BOM、全角空格），
HEX()可辅助判断：SELECT HEX(' 15/03/2024')（注意开头是全角空格） - 确认系统时区和
lc_time_names设置，比如%M解析英文月份依赖当前 locale，SET lc_time_names = 'en_US';可临时固定
在 INSERT 和 WHERE 中安全使用 STR_TO_DATE
直接在 INSERT 里嵌套 STR_TO_DATE 很常见，但要注意目标字段类型兼容性。例如往 DATE 字段插 STR_TO_DATE('2024-03-15 14:30:00', '%Y-%m-%d %H:%i:%s') 没问题，结果会自动截断为日期部分；但反过来，往 DATETIME 字段插只含日期的字符串，就得确保格式符不带时间，否则可能得补 00:00:00。
在 WHERE 子句中用它做条件要格外小心性能：
-
WHERE STR_TO_DATE(create_str, '%d/%m/%Y') = '2024-03-15'无法走索引，哪怕create_str上有索引 - 更优做法是提前转换并存到生成列或额外字段，或改用范围查询：
WHERE create_str BETWEEN '15/03/2024' AND '15/03/2024'（仅当格式严格统一且可排序时） - 如果只是偶尔查，加个
COALESCE(STR_TO_DATE(...), '0000-00-00')可避免NULL干扰比较逻辑
STR_TO_DATE 和 DATE_FORMAT 容易混淆的边界
STR_TO_DATE 和 DATE_FORMAT 是一对逆操作，但方向绝对不能颠倒。典型误用：DATE_FORMAT('2024-03-15', '%d/%m/%Y') 看似能“转格式”，但它要求第一个参数必须是日期类型，传字符串会先被 MySQL 尝试隐式转换——一旦格式非法（如 '15-03-2024'），就变成 0000-00-00 再格式化，结果是 '00/00/0000'，毫无提示。
真正安全的流程是：
- 字符串 →
STR_TO_DATE(...)→ 得到合法日期类型 - 再用
DATE_FORMAT(结果, '%d/%m/%Y')输出所需格式 - 中间任何一步返回
NULL，都说明原始字符串或格式符有问题，必须拦截处理
最常被忽略的是：不同地区习惯的分隔符（.、-、/、空格）、月份名称大小写、甚至中文数字（MySQL 原生不支持「二〇二四」这类），这些都得在进库前清洗干净，STR_TO_DATE 不负责容错。
