STR_TO_DATE解析失败最常见报错是静默返回NULL，因格式不匹配（如缺秒却写%s）；中文需原样匹配字面量；不支持时区和毫秒，须预处理；时区设置影响存储结果。
STR_TO_DATE解析失败的常见报错是什么
最常遇到的是返回 NULL，且没有明确错误提示——MySQL 默认静默失败。比如执行 STR_TO_DATE('2023-05-20 14:30', '%Y-%m-%d %H:%i:%s')，输入没秒但格式写了 %s，结果就是 NULL。这不是bug，是设计行为：只要任意部分不匹配，整个函数就放弃并返回 NULL。
验证是否真失败，别只看结果，加个判断更稳妥：
SELECT
str_time,
STR_TO_DATE(str_time, '%Y-%m-%d %H:%i') AS parsed,
CASE WHEN STR_TO_DATE(str_time, '%Y-%m-%d %H:%i') IS NULL
THEN 'parse failed' ELSE 'ok' END AS status
FROM (SELECT '2023-05-20 14:30' AS str_time) t;
非标准格式如“2023年5月20日 14:30”怎么写格式符
中文字符必须原样出现在格式字符串中，不能省略或替换。MySQL 的 STR_TO_DATE 支持字面量中文，但前提是当前 session 的字符集能正确识别（推荐用 utf8mb4）。
-
'%Y年%m月%d日 %H:%i'→ 匹配'2023年05月20日 14:30' -
'%Y年%c月%d日 %H:%i'→ 匹配'2023年5月20日 14:30'（%c不补零，%m补零） - 注意：空格、冒号、中文标点都得一模一样，多一个空格也会失败
实操建议：先用 SELECT STR_TO_DATE('2023年5月20日 14:30', '%Y年%c月%d日 %H:%i'); 单独测试，确认返回非 NULL 再嵌入业务 SQL。
带时区或毫秒的时间串怎么处理
MySQL 5.7 及以前的 STR_TO_DATE **完全不支持时区偏移（如 +0800）和毫秒（.123）**。遇到 '2023-05-20T14:30:45+0800' 或 '2023-05-20 14:30:45.123' 这类字符串，必须预处理。
- 去掉时区：用
REPLACE()或正则（MySQL 8.0+）先截掉+0800部分 - 截断毫秒：用
SUBSTRING_INDEX(str_time, '.', 1)拿到秒前部分 - MySQL 8.0+ 可用
REGEXP_SUBSTR提取主时间部分，再喂给STR_TO_DATE
例如处理 ISO 带毫秒格式：STR_TO_DATE(SUBSTRING_INDEX('2023-05-20 14:30:45.123', '.', 1), '%Y-%m-%d %H:%i:%s')。
为什么用 STR_TO_DATE 后插入失败或时间偏移
根本原因常被忽略：MySQL 会把解析出的时间值按当前 session 时区解释。比如你用 STR_TO_DATE('2023-05-20 14:30', '%Y-%m-%d %H:%i') 得到一个 datetime 值，但它在存储时会受 time_zone 影响。
- 如果 session 时区是
+08:00，而字段是DATETIME类型，值就按本地时间存；如果是TIMESTAMP，则会转成 UTC 存储 - 跨时区同步数据时，容易出现“明明解析对了，查出来却差8小时”的情况
- 稳妥做法：解析后显式转成 UTC，或统一设置 session 时区为
+00:00再解析
执行前加一句：SET time_zone = '+00:00';，尤其在导入脚本或存储过程中。
