TO_DATE函数必须严格匹配格式串，因其完全依赖指定格式模型解析字符串，不匹配则报ORA-01861错误；常见问题包括分隔符不一致、时间部分缺失、大小写混淆（如MM与mi）、语言环境干扰及静默日期修正等。
Oracle 中不能直接用字符串参与日期运算，必须用 TO_DATE 显式转换，否则会隐式转换失败或结果不可靠。
为什么 TO_DATE 的格式串必须和字符串严格匹配
Oracle 不会自动识别 “2024-05-20” 是年月日还是月日年。TO_DATE 完全依赖你写的格式模型解析字符串，哪怕多一个空格、少一个分隔符都会报 ORA-01861: literal does not match format string。
常见踩坑点：
- 字符串是
'2024/05/20'，却写成TO_DATE('2024/05/20', 'YYYY-MM-DD')→ 报错 - 字符串含时间如
'2024-05-20 14:30:00'，只写'YYYY-MM-DD'→ 时间部分被截断为00:00:00，且不报错，但逻辑出错 - 使用
DD/MM/YYYY解析'15-03-2024'（用了短横线）→ 格式符和实际分隔符不一致，必报错
TO_DATE 常见格式符与实际字符串对照示例
格式符大小写敏感，MM（月）和 mm（分钟）完全不同；YY 和 YYYY 对两位年份的解释也不同（比如 '01' 在 YY 下可能是 2001，在 RR 下可能是 1901）。
安全建议：
- 始终用
YYYY而非YY，避免世纪歧义 - 时间部分务必补全：有秒就写
HH24:MI:SS，有毫秒需配合FF3等 - 不确定字符串来源时，先用
REGEXP_LIKE验证格式再转换，例如：WHERE REGEXP_LIKE(date_str, '^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}$')
在 INSERT / UPDATE 中用 TO_DATE 的注意事项
如果目标列是 DATE 类型，而源数据是字符串（比如从 CSV 导入或接口传入），必须在 SQL 里显式转换。否则 Oracle 可能调用 NLS_DATE_FORMAT 做隐式转换——这个值因 session 而异，上线后容易出问题。
典型错误写法：
INSERT INTO orders (order_date) VALUES ('2024-05-20');
正确写法：
INSERT INTO orders (order_date) VALUES (TO_DATE('2024-05-20', 'YYYY-MM-DD'));
更稳妥的做法是：在应用层或存储过程中统一用绑定变量 + 显式 TO_DATE，避免拼接字符串。
遇到 NLS 语言/地区设置干扰怎么办
当字符串含中文月份（如 ‘2024年5月20日’）或英文缩写（如 ‘20-MAY-2024’），默认 TO_DATE 会按当前 session 的 NLS_DATE_LANGUAGE 解析。一旦 session 切换（比如不同用户登录），可能突然报错。
解决方法是显式指定语言：
TO_DATE('20-MAY-2024', 'DD-MON-YYYY', 'NLS_DATE_LANGUAGE=AMERICAN')
或者用数字格式彻底规避语言依赖，比如把 ‘MAY’ 改成 ‘05’ 再处理。
最麻烦的不是不会写 TO_DATE，而是忘了它不校验业务逻辑——比如把 '2024-02-30' 转成日期，Oracle 默认不报错（会转成 2024-03-01），这种静默修正往往埋下数据质量隐患。
