STR_TO_DATE 转不了 "2023-01-01T12:34:56"？得配对的格式符

很多开发者第一次用MySQL的STR_TO_DATE函数时，容易把它当成一个智能的日期解析器。其实不然，它更像一个严格的格式校对员，必须一字不差地匹配。就拿标准的ISO 8601时间格式"2023-01-01T12:34:56"来说，如果你用'%Y-%m-%d %H:%i:%s'去解析，结果铁定是NULL。问题出在哪？就出在那个不起眼的字母T上——它被当成了需要解析的部分，而你的格式字符串里却没有对应的通配符。

正确的做法其实很简单：把T当作一个普通的字面量字符，原封不动地写进格式字符串里。

STR_TO_DATE('2023-01-01T12:34:56', '%Y-%m-%dT%H:%i:%s')

这里有几个关键点需要牢记：

• 字面量必须匹配：所有非通配符的字符，比如连接日期和时间的T、日期中的短横线-、时间中的冒号:，甚至是空格，都必须一模一样地出现在格式字符串中。
• 注意时钟制式：%H代表24小时制，而%h是12小时制（需要搭配%p来指定AM/PM）。用错了，转换就会失败。
• 处理毫秒的坑：如果字符串末尾带了毫秒，比如"2023-01-01T12:34:56.123"，在MySQL 5.6及以上版本可以用%f来解析。但要注意，%f默认期望的是6位微秒数。如果你的毫秒位数不足，可能需要先补零或做截断处理。

从 "Jan 01, 2023" 或 "01/Jan/2023" 这类英文日期转时间戳

处理带英文月份缩写的日期字符串，又是另一个常见的“雷区”。这里必须使用%b（对应Jan、Feb这类缩写）或%M（对应January、February全称）。但更关键的是，MySQL解析这些英文月份时，依赖的是一个叫做lc_time_names的系统变量，它决定了函数能识别哪种语言的月份名。

一个典型的翻车场景是：在中文操作系统环境下，执行STR_TO_DATE('Jan 01, 2023', '%b %d, %Y')却返回了NULL。这很可能是因为数据库会话的lc_time_names被设置成了非英语（比如zh_CN），它自然就不认识“Jan”了。这种情况在一些定制化的Docker镜像或云数据库实例中时有发生。

• 先查后动：动手前，用SELECT @@lc_time_names;看看当前设置是什么。
• 临时切换：如果确认数据是英文格式，可以在会话中临时设置：SET lc_time_names = 'en_US';。
• 格式严格：%b只认前三个字母，%M需要完整月份名。函数本身不区分大小写，但字符串中的逗号、空格等分隔符必须与格式串严格对应。
• 终极建议：如果数据源格式固定，最稳妥的办法是在应用层就将这些“非标”日期统一转换成YYYY-MM-DD标准格式，再存入数据库，一劳永逸地避免本地化问题。

为什么 STR_TO_DATE('20230101', '%Y%m%d') 有时返回 NULL？

有时候，明明格式字符串'%Y%m%d'和输入值'20230101'看起来严丝合缝，函数却还是返回了NULL。这种时候，别怀疑语法，问题大概率出在“看不见”的地方。

输入的字符串里可能混入了不可见字符。比如，从网页表单或API接口传来的数据，末尾多了一个回车符\r、换行符\n，甚至是文件开头的BOM标记。又或者，存储这个字符串的字段类型是CHAR(8)，不足8位的部分被数据库用空格填充了，导致实际值变成了'20230101 '。

• 用HEX函数透视：这是排查此类问题的利器。SELECT HEX('20230101 ')会返回'323032333031303120'，末尾的20就是空格的十六进制码，让问题无所遁形。
• 先清洗再转换：在转换前使用TRIM()函数去除首尾空格：STR_TO_DATE(TRIM('20230101 '), '%Y%m%d')。
• 注意字段类型：对于CHAR类型字段，TRIM()几乎是必备操作。即使用VARCHAR，也要警惕前端或ORM框架可能无意中注入的空白字符。
• 版本差异：虽然MySQL 8.0.19之后对STR_TO_DATE的空格处理稍微宽松了些，但在老版本或开启了严格SQL模式的数据库中，依然会严格执行标准。别把希望寄托在数据库的“宽容”上。

替代方案：用 DATE_FORMAT + CAST 组合兜底

当面对的数据源格式杂乱无章，既有"2023-01-01"，又有"01/01/2023"，还混着"20230101"时，与其写一堆CASE WHEN配合不同格式的STR_TO_DATE，不如换个思路：先统一标准，再行转换。

一个实用的迂回策略是：

• 提取数字核心：使用REGEXP_REPLACE(col, '[^0-9]', '')，把字符串中所有非数字字符都替换掉，得到一个纯数字串。
• 按长度判断：如果结果是14位，可以尝试当作YYYYMMDDHHIISS格式解析；如果是8位，则当作YYYYMMDD。之后再交给STR_TO_DATE处理。
• 认清数据库的职责：必须清醒认识到，MySQL毕竟不是专业的文本处理器。在数据库层进行过于复杂的字符串清洗和格式判断，不仅会拖慢查询性能，也给调试和维护带来困难。对于极其混乱的数据，最稳健的方案还是在应用层完成清洗和标准化，再将干净的数据入库。

说到底，处理日期转换时，真正的挑战往往不是记住函数的参数，而是应对数据中不可预见的“杂质”和环境的微妙差异。一个值得推荐的习惯是：在转换时，额外保留一列原始字符串，并对转换结果做IS NULL检查。这份谨慎，远比在深夜翻查错误日志来得高效得多。