DATE_FORMAT不能用于更新日期字段，因其返回字符串而非DATE类型，会导致解析失败、数据损坏或隐式转换；应使用STR_TO_DATE清洗乱格式日期，并配合COALESCE和WHERE条件安全处理多格式数据。
别用 DATE_FORMAT 去“更新”日期字段——它根本不是干这个的。 你看到数据没变、报错、变成 0000-00-00 或者字段类型被悄悄转成字符串，基本都是因为误用了格式化函数当清洗工具。
为什么 DATE_FORMAT 在 UPDATE 里会出问题
DATE_FORMAT(date_col, '%Y-%m-%d') 返回的是字符串（VARCHAR），不是 DATE。如果你把它直接赋给一个 DATE 类型字段，MySQL 会尝试把字符串再解析一遍——但这次解析不受你控制，可能失败、截断、或隐式转成默认值（比如 0000-00-00）。更糟的是，如果原始字段是 DATETIME，你还可能丢掉时间部分。
- 执行
UPDATE t SET dt = DATE_FORMAT(dt, '%Y-%m-%d')后查SHOW COLUMNS FROM t，你会发现字段类型没变，但值可能已损坏 - 错误日志里常出现
Incorrect datetime value或警告Data truncated for column 'dt' - Oracle 用户注意：
DATE_FORMAT根本不存在，得用TO_DATE；SQL Server 用CONVERT或TRY_CONVERT
真正该用的函数是 STR_TO_DATE
清洗乱格式日期，核心动作是“把字符串按规则转成真日期”，不是“把日期转成某种字符串”。STR_TO_DATE 才是输入端的解析函数。
- 原始数据是
'01/15/2023'？用STR_TO_DATE(date_col, '%m/%d/%Y') - 原始是
'15-01-2023'？用STR_TO_DATE(date_col, '%d-%m-%Y') - 原始是
'20230115'？用STR_TO_DATE(date_col, '%Y%m%d') - 务必加
WHERE条件过滤：只处理匹配格式的行，避免把NULL或'abc'也塞进去导致整列变NULL
多种格式混在一起，用 COALESCE 安全兜底
现实表里 rarely 只有一种乱格式。硬写嵌套 IF 易错且难维护，COALESCE 是更清晰的选择——它按顺序试每个 STR_TO_DATE，第一个成功就返回，后面不执行。
UPDATE orders SET order_date = COALESCE(
STR_TO_DATE(date_str, '%m/%d/%Y'),
STR_TO_DATE(date_str, '%d-%m-%Y'),
STR_TO_DATE(date_str, '%Y-%m-%d'),
STR_TO_DATE(date_str, '%Y%m%d')
) WHERE date_str REGEXP '^[0-9/\-]{8,10}$';- 所有
STR_TO_DATE都失败时，结果为NULL—— 所以WHERE条件必须提前排除明显非法值（比如含字母、长度超界） - 如果业务不允许
NULL，得在COALESCE最后补个默认值，例如STR_TO_DATE('1970-01-01', '%Y-%m-%d') - 执行前先
SELECT date_str, COALESCE(...) AS cleaned FROM ... WHERE ... LIMIT 10验证逻辑
更新后还得检查时区和非法日期
即使 STR_TO_DATE 成功了，也可能踩坑：比如 '2024-02-31' 这种假日期，在严格模式下会直接报错；或者字段定义为 TIMESTAMP，但服务器时区设置让值偏移。
- 查非法日期：
SELECT * FROM t WHERE order_date = '0000-00-00' OR order_date IS NULL - 确认时区：
SELECT @@time_zone, @@system_time_zone；TIMESTAMP字段受此影响，DATETIME不受影响 - 如果表结构本身是
VARCHAR存日期，清洗完应尽快ALTER TABLE ... MODIFY COLUMN ... DATE，别长期容忍字符串存时间
最常被跳过的步骤是：没验证原始数据分布就批量跑 UPDATE。花三分钟 SELECT COUNT(*) GROUP BY LENGTH(date_col), date_col REGEXP '...'，比修三天脏数据强。
