STR_TO_DATE()需严格匹配格式，失败返回NULL而非'0000-00-00'；必须用正确格式符（如%Y/%m/%d）、分组验证多格式数据，INSERT/UPDATE须显式转换，时区需应用层处理。
直接用 STR_TO_DATE() 但必须匹配格式
MySQL 不会自动识别 '2023-10-05 14:30:45' 这类字符串为 DATETIME，除非它严格符合默认格式（'YYYY-MM-DD HH:MM:SS'）。一旦格式有偏差——比如带中文、缺前导零、顺序颠倒、用斜杠分隔——直接赋值或隐式转换就会变成 '0000-00-00 00:00:00' 或报错（开启严格模式时）。
安全做法是显式调用 STR_TO_DATE()，并传入与输入字符串**完全一致**的格式模型：
SELECT STR_TO_DATE('2023/10/05 14:30', '%Y/%m/%d %H:%i');
常见格式符必须对得上：
-
%Y：4 位年份；%y是 2 位，别混用 -
%m：01–12 的月；%c是 1–12（不补零），遇到'2023-5-5'就得用%c -
%d：01–31 的日；%e是 1–31（不补零） -
%H：24 小时制（00–23）；%h是 12 小时制（01–12），还依赖%p（AM/PM）
转换失败时默认返回 NULL，不是 0000 值
STR_TO_DATE() 在解析失败时返回 NULL，而不是危险的 '0000-00-00 00:00:00'。这点很关键——它让你能主动捕获异常，而不是让脏数据悄悄入库。
例如这批数据里混着非法日期 '2023-02-30' 或乱码 'abc'：
SELECT STR_TO_DATE('2023-02-30', '%Y-%m-%d'); -- 返回 NULL
你可以配合 COALESCE() 或 IFNULL() 提供兜底值，或用 WHERE 过滤掉无效行：
- 只保留能转成功的记录：
WHERE STR_TO_DATE(date_str, '%Y-%m-%d') IS NOT NULL - 转失败就填当前时间：
COALESCE(STR_TO_DATE(date_str, '%Y-%m-%d'), NOW()) - 转失败标为特殊值便于排查：
IFNULL(STR_TO_DATE(date_str, '%Y-%m-%d'), 'INVALID')（注意类型需兼容）
INSERT / UPDATE 时别依赖隐式转换
哪怕字符串看起来“很标准”，比如 '2023-10-05 14:30:45'，也不要直接写进 INSERT 语句里指望 MySQL 自动转：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
INSERT INTO logs (created_at) VALUES ('2023-10-05 14:30:45'); -- 危险！在严格模式下可能报错
更稳妥的方式是全程用 STR_TO_DATE() 包裹：
INSERT INTO logs (created_at) VALUES (STR_TO_DATE('2023-10-05 14:30:45', '%Y-%m-%d %H:%i:%s'));
尤其要注意时区问题：MySQL 的 STR_TO_DATE() 总是按**会话时区**解析，不会识别字符串里的时区标识（如 '2023-10-05T14:30:45+08:00'）。含时区的字符串必须先剥离或用应用层处理。
批量转换前务必验证格式一致性
现实数据往往混杂多种格式：有的带毫秒，有的用中文分隔符，有的缺秒，有的年份只有两位。直接套一个 STR_TO_DATE() 格式会大量返回 NULL。
先用正则粗筛格式分布：
SELECT
COUNT(*) cnt,
CASE
WHEN date_str REGEXP '^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}$' THEN 'standard'
WHEN date_str REGEXP '^\d{4}/\d{1,2}/\d{1,2} \d{1,2}:\d{2}$' THEN 'slash-hour'
ELSE 'other'
END fmt
FROM raw_table GROUP BY fmt;
再按格式分组，各自指定对应 STR_TO_DATE() 模型。别试图用一个万能格式串应付所有情况——STR_TO_DATE() 不支持模糊匹配或备选格式。
真正麻烦的点在于：格式不统一 + 业务不允许丢数据 + 要求 DATETIME 精确到秒。这时候就得在应用层预处理，或者加中间清洗表，MySQL 本身没捷径。
