安全修正非法日期需在BEFORE INSERT/UPDATE触发器中用STR_TO_DATE()配合IS NULL判断逐格式尝试解析，成功则赋值，失败则设NULL或保留旧值；必须分层防护，应用层校验为主，触发器仅作兜底。
触发器里怎么安全地修正 INSERT 进来的非法日期？
不能直接在触发器里用 STR_TO_DATE() 或 DATE() 强转所有输入——遇到空字符串、'0000-00-00'、'2024-13-01' 会报错并中断整个语句。MySQL 触发器中函数调用失败即事务回滚，没机会兜底。
真正可行的做法是：先用 STR_TO_DATE() 尝试解析，再用 IS NULL 判断是否成功，只对有效格式赋值，其余统一设为 NULL 或默认值（如 CURDATE()）：
DELIMITER $$
CREATE TRIGGER normalize_date_before_insert
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
SET NEW.order_date = CASE
WHEN STR_TO_DATE(NEW.order_date, '%Y-%m-%d') IS NOT NULL THEN STR_TO_DATE(NEW.order_date, '%Y-%m-%d')
WHEN STR_TO_DATE(NEW.order_date, '%d/%m/%Y') IS NOT NULL THEN STR_TO_DATE(NEW.order_date, '%d/%m/%Y')
WHEN STR_TO_DATE(NEW.order_date, '%Y%m%d') IS NOT NULL THEN STR_TO_DATE(NEW.order_date, '%Y%m%d')
ELSE NULL
END;
END$$
DELIMITER ;- 必须用
BEFORE INSERT，AFTER触发器无法修改NEW值 - 多个
STR_TO_DATE()分支按常见格式从高到低排列，避免'01/02/2024'被误判成'%Y-%m-%d' - 别忘了
DELIMITER切换，否则;会让 MySQL 提前结束定义
为什么 UPDATE 触发器也要做同样处理？
用户可能通过 UPDATE orders SET order_date = '31-12-2023' WHERE id = 123; 直接写入错误格式，而这个值会原样存进字段——如果字段类型是 DATE，MySQL 会静默转成 '0000-00-00'（取决于 SQL mode），后续查询时就再也分不清是真零值还是脏数据。
所以 BEFORE UPDATE 触发器逻辑必须和 INSERT 完全一致，且要额外检查 NEW.order_date != OLD.order_date 避免无谓计算：
CREATE TRIGGER normalize_date_before_update
BEFORE UPDATE ON orders
FOR EACH ROW
BEGIN
IF NEW.order_date != OLD.order_date THEN
SET NEW.order_date = CASE
WHEN STR_TO_DATE(NEW.order_date, '%Y-%m-%d') IS NOT NULL THEN STR_TO_DATE(NEW.order_date, '%Y-%m-%d')
WHEN STR_TO_DATE(NEW.order_date, '%d/%m/%Y') IS NOT NULL THEN STR_TO_DATE(NEW.order_date, '%d/%m/%Y')
WHEN STR_TO_DATE(NEW.order_date, '%Y%m%d') IS NOT NULL THEN STR_TO_DATE(NEW.order_date, '%Y%m%d')
ELSE OLD.order_date -- 保持原值，不强行置 NULL
END;
END IF;
END$$- 这里选择保留旧值而非强制
NULL，更符合业务容错预期 -
STR_TO_DATE()对NULL输入返回NULL，不会报错，可直接参与判断 - 注意：如果字段允许
NULL，OLD.order_date可能是NULL，比较时要用安全等于，但此处用!=已足够（因NEW是显式传入的非NULL字符串）
触发器归一化 vs 应用层校验，哪个更靠谱？
触发器只能管住直接走 SQL 的写入，拦不住 ORM 批量插入（如 Django bulk_create）、LOAD DATA、或已绕过触发器的 INSERT IGNORE。它本质是最后一道防线，不是替代方案。
真正健壮的做法是分层控制：
- 应用层接收参数时，用语言原生日期库（如 Python
datetime.strptime）提前校验并标准化，失败则拒收 - 数据库字段类型必须是
DATE或DATETIME，禁止用VARCHAR存日期——否则触发器修了格式，索引和范围查询仍失效 - 触发器只负责兜底：修复少量遗留脚本、DBA 临时 SQL、或上游系统未按约定传值的情况
漏掉任何一层，都可能让 '2024-02-30' 这种数据悄悄入库，等报表出错才被发现。
性能和兼容性上最容易被忽略的点
触发器本身开销极小，但每个 STR_TO_DATE() 调用都会触发一次字符串解析，高频写入表（比如每秒上千条订单）下，多几个格式分支就会明显拖慢 INSERT 延迟。
更隐蔽的问题是 MySQL 版本差异：STR_TO_DATE() 在 5.7 和 8.0 对 '2024-00-01' 的处理不同，前者可能返回 NULL，后者可能抛错——必须在目标环境实测所有异常输入。
- 上线前用真实脏数据集压测，例如生成 10 万条含
'/'、'.'、中文年月日的测试数据跑一遍触发器 - 如果表已有历史脏数据，触发器对
UPDATE生效，但不会自动修复存量；得用UPDATE ... SET col = STR_TO_DATE(col, ...)单独清洗 - 不要在分区表或有复制延迟的从库上依赖触发器逻辑——主从触发器执行顺序可能不一致
