TO_DATE格式符必须显式且严格匹配字符串，否则报ORA-01843/ORA-01861；TO_CHAR需固定语言环境或用数字格式；隐式转换致索引失效；NLS_DATE_FORMAT不可靠，应始终显式转换。

TO_DATE 用错格式符导致 ORA-01843 或 ORA-01861

隐式转换最常翻车的地方，就是把字符串塞给 to_date 却没配对格式模型。比如 '2024-05-20' 直接喂给 to_date(col)，oracle 默认按 dd-mon-rr 解析，遇到 '2024' 就报 ora-01843: not a valid month。

必须显式写全格式符，且和输入字符串严格一致：

• TO_DATE('2024-05-20', 'YYYY-MM-DD') ✅
• TO_DATE('20/05/2024', 'DD/MM/YYYY') ✅
• TO_DATE('2024-05-20') ❌（依赖 NLS_DATE_FORMAT，不可靠）
• TO_DATE('2024-05-20', 'YYYY/MM/DD') ❌（斜杠不匹配短横线）

注意：格式符大小写敏感，'yyyy-mm-dd' 无效，必须大写 'YYYY-MM-DD'。

TO_CHAR 忽略语言环境导致月份/星期显示异常

TO_CHAR(sysdate, 'Month') 在中文会话里输出“五月”，英文会话里是“May”——但如果你硬编码了判断逻辑，比如 WHERE TO_CHAR(date_col, 'Month') = 'May'，换环境就失效。

更稳的做法是固定语言环境或改用数字：

• 强制英文：TO_CHAR(date_col, 'Month', 'NLS_DATE_LANGUAGE=AMERICAN')
• 改用数字月份：TO_CHAR(date_col, 'MM') 或 EXTRACT(MONTH FROM date_col)
• 避免用 'Day' 做条件，改用 'D'（周内第几天，1=周日）或 'DY'（缩写，但需指定语言）

别依赖默认 NLS 设置，它可能被 ALTER SESSION 动态改掉。

字符串拼接 + 隐式 TO_DATE 引发性能崩溃

写 WHERE date_col > '2024-05-20' 看似省事，实际触发隐式转换：Oracle 把字符串转成日期再比，可能导致索引失效（尤其当列上有函数索引或分区键时）。

正确姿势是让日期列保持原生类型：

• ✅ WHERE date_col > TO_DATE('2024-05-20', 'YYYY-MM-DD')
• ✅ WHERE date_col >= DATE '2024-05-20'（ANSI 日期字面量，最简洁）
• ❌ WHERE TO_CHAR(date_col, 'YYYY-MM-DD') > '2024-05-20'（函数在列上，索引失效）

执行计划里如果看到 FULL TABLE SCAN 或 FUNCTION SCAN，八成是这里动了手脚。

NLS_DATE_FORMAT 不是救命稻草，反而是隐患放大器

有人想一劳永逸，在会话里设 ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD'，以为从此 TO_DATE(col) 就安全了。其实只是把问题藏得更深：

• 不同用户会话 NLS 设置可能不同，SQL 移到另一个环境就崩
• 应用连接池可能复用会话，NLS 状态污染不可控
• TO_DATE 没带格式符时仍可能受 NLS_TERRITORY 影响（比如日期分隔符）

真正可靠的写法永远是：显式格式符 + 显式类型转换。NLS 设置只该用于调试或报表输出，不该参与核心逻辑。

最麻烦的不是写错一次，而是错得刚好在测试环境跑通，上线后某个特殊日期格式才暴露——比如 '05/20/24' 在美式环境下是 5 月，英式下却是 20 月。