STR_TO_DATE严格按格式字符串匹配输入，错配即返回NULL。需确保格式符与日期字符串完全一致，如“2023-05-12 14:30:45”必须用'%Y-%m-%d %H:%i:%s'，斜杠、缺位、顺序错误均失效；中文、AM/PM、空格、时区等须显式处理；返回DATETIME类型，宜建生成列+索引提升查询性能。
STR_TO_DATE 不是万能时间解析器，它只按你给的格式字符串严格匹配，格式错一点就返回 NULL，且不报错——这是绝大多数人踩坑的起点。
STR_TO_DATE 格式字符串必须和输入字符串完全对齐
比如字段值是 "2023-05-12 14:30:45"，你写 STR_TO_DATE(col, '%Y-%m-%d %H:%i:%s') 才行；写成 '%Y/%m/%d %H:%i:%s'（用斜杠）或漏掉秒（'%Y-%m-%d %H:%i'）都会返回 NULL。
- 常见错配：
"12/05/2023"要用'%d/%m/%Y'，不是'%m/%d/%Y'（MySQL 默认不猜顺序） - 带中文的如
"2023年05月12日"必须写'%Y年%m月%d日'，不能省略“年”“月”“日”字 - 12小时制带 AM/PM：用
'%m/%d/%Y %h:%i:%s %p'，%h是 01–12，%H是 00–23，混用直接失配
遇到 NULL 别急着改 SQL，先验证输入和格式是否真匹配
用 SELECT 单独测试最可靠：
SELECT
col AS raw_str,
STR_TO_DATE(col, '%Y-%m-%d') AS parsed,
LENGTH(col) AS len,
col REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2}$' AS matches_pattern
FROM your_table
LIMIT 5;
这样能一眼看出是格式写错了，还是原始数据里混了空格、全角字符、多余字母（比如 "2023-05-12T00:00:00" 中的 T）。
- 空格敏感：字符串开头/结尾有空格？加
TRIM()再传给STR_TO_DATE - 时区信息会被忽略：
"2023-05-12 14:30:45+08:00"中的+08:00无法被解析，得先用SUBSTRING_INDEX或正则截掉 - 毫秒部分不支持：
'%f'在 MySQL 5.6.4+ 可用，但仅限于微秒（6位），且输入必须是"123456"这种纯数字，不能带小数点
STR_TO_DATE 返回的是 DATETIME，不是字符串，别再套 CAST 或 CONCAT 强转
它输出的就是 MySQL 原生时间类型，可直接参与比较、计算、索引（如果字段上建了函数索引或用了生成列）：
- 正确用法：
WHERE STR_TO_DATE(log_time, '%Y%m%d%H%i') > '2023-01-01' - 错误习惯：写
CAST(STR_TO_DATE(...) AS CHAR)再做字符串比较——既慢又易出错 - 性能注意：在 WHERE 中对字段用
STR_TO_DATE(col, ...)会阻止索引使用；如需高频查询，建议提前用生成列存解析结果并建索引
真正麻烦的从来不是函数怎么写，而是原始数据杂乱无章又没文档——每次加新数据源，都得重看一遍那几行 STR_TO_DATE 调用，确认格式符有没有悄悄失效。
