STR_TO_DATE解析日期需严格匹配格式，遇空格、非常规符号或格式符错误均静默返回NULL；应先TRIM/REPLACE预处理，用正确格式符（如'%M'而非'%m'），避免WHERE中直接调用以保索引性能。
STR_TO_DATE 不能直接解析带空格或多余符号的日期文本
MySQL 的 STR_TO_DATE 对输入格式极其敏感，遇到类似 "2024-05-20 "（末尾空格）、"2024/05/20T14:30:00" 或 "May 20, 2024" 这类非标准字符串时，会静默返回 NULL，且不报错——这是最常被忽略的问题源头。
实操建议：
- 先用
TRIM()清除首尾空白：STR_TO_DATE(TRIM(date_str), '%Y-%m-%d') - 对含时间戳的 ISO 格式（如
"2024-05-20T14:30:00"），需先替换掉T：REPLACE(date_str, 'T', ' ')，再传入STR_TO_DATE(..., '%Y-%m-%d %H:%i:%s') - 英文月份名必须用
'%M'（不是'%m'），且大小写敏感：STR_TO_DATE('May 20, 2024', '%M %d, %Y')可行，但'may'会失败
格式符写错会导致 NULL 而非报错，调试要靠 SELECT 验证
STR_TO_DATE 不抛异常，只返回 NULL。你写的格式符哪怕只差一个字母（比如把 '%Y' 写成 '%y'），结果都不可靠。
常见格式符陷阱：
-
'%y'解析两位年份（24 → 2024？错，它默认是2024仅当上下文明确；更稳妥用'%Y'） -
'%d'要求日为两位（'5'不匹配'%d'，得用'%e'），但'%e'在 Windows 版 MySQL 中可能不支持 - 中文或全角字符（如
"2024年05月20日"）无法用原生STR_TO_DATE解析，必须先用REPLACE替换掉“年”“月”“日”
调试时务必单独测试：
SELECT STR_TO_DATE('2024-5-20', '%Y-%m-%d') AS result; —— 返回 NULL 就说明格式不匹配。
性能敏感场景下避免在 WHERE 条件中反复调用 STR_TO_DATE
如果表里存的是字符串日期（如 date_str VARCHAR(32)），又在 WHERE STR_TO_DATE(date_str, '%Y%m%d') > '2024-01-01' 中使用，MySQL 无法走索引，全表扫描不可避免。
更优做法：
- 新增一个
DATE类型列，用UPDATE ... SET date_col = STR_TO_DATE(date_str, '%Y%m%d')一次性转换并建立索引 - 若只能临时处理，至少把转换提到子查询或 CTE 中，避免重复计算：
SELECT * FROM (SELECT *, STR_TO_DATE(date_str, '%Y-%m-%d') AS d FROM t) t2 WHERE t2.d > '2024-01-01';
- 注意时区：
STR_TO_DATE结果是无时区的DATE或DATETIME，若原始文本含时区（如"2024-05-20+08:00"），它会被直接截断
替代方案：正则预处理 + STR_TO_DATE 更可靠
面对高度混乱的输入（如混杂 "2024.05.20"、"20/05/2024"、"20240520"），硬靠多个 STR_TO_DATE 分支判断效率低且易漏。
推荐组合拳：
- 用
REGEXP_REPLACE（MySQL 8.0+）统一标准化格式：REGEXP_REPLACE(date_str, '^([0-9]{4})\.([0-9]{1,2})\.([0-9]{1,2})$', '$1-$2-$3') - 对不同分隔符做多轮替换，最终归一为
YYYY-MM-DD形式，再喂给STR_TO_DATE(..., '%Y-%m-%d') - 旧版 MySQL（REPLACE 模拟，但逻辑变复杂，建议优先升级或前置清洗
真正麻烦的从来不是函数本身，而是原始数据里那些没文档、没约束、没人认领的“日期”字符串——它们往往连空格数量都不一致。
