NLS_DATE_FORMAT是会话级参数，修改spfile仅对新连接生效，已有会话不受影响；ALTER SESSION只作用于当前会话，断连即失效；真正安全的做法是避免隐式转换，代码中显式使用DATE类型或TO_DATE等函数。
改 NLS_DATE_FORMAT 会影响所有新连接，但不改已有会话
oracle 的 nls_date_format 是会话级参数，修改数据库初始化参数（如 spfile 或 pfile）只对后续新建的连接生效。已连上的会话仍保持原格式，哪怕你重启了数据库实例——因为它们是在登录时从参数快照里读取的。
- 查当前全局默认值：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'nls_date_format'; - 改前先确认是否真有必要：多数应用应显式用
TO_DATE(..., 'YYYY-MM-DD HH24:MI:SS')或绑定变量，而非依赖隐式转换 - 生产库慎用
ALTER SYSTEM SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS' SCOPE=SPFILE;，改完必须重启实例才生效
ALTER SESSION SET NLS_DATE_FORMAT 只作用于当前会话
开发或脚本调试时常用这个命令临时调整，但它不会写入任何配置文件，断开重连就失效。容易误以为“已经改好了”，结果上线后 SQL 报 ORA-01843: not a valid month。
- 典型错误场景：在 SQL*Plus 里执行了
ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-RR';，然后跑了一堆INSERT INTO t VALUES ('01-JAN-23');—— 换个客户端或重连就失败 - 如果用 JDBC，驱动默认可能走
AMERICAN区域设置，ALTER SESSION命令需在获取连接后第一时间执行 - Spring Boot + Oracle 项目中，别指望在
application.yml里配个spring.datasource.hikari.connection-init-sql=ALTER SESSION...就一劳永逸，某些连接池（如 HikariCP）会复用连接，init-sql 只在首次创建时运行
修改 spfile 后不重启，新会话仍用旧格式
SCOPE=SPFILE 不等于立即生效，它只是把值记进二进制服务器参数文件。Oracle 实例运行时仍按内存里的参数副本工作，所以必须重启才能让新连接读到新值。
- 验证是否生效：重启后开一个全新 SQL*Plus 连接，执行
SELECT SYSDATE FROM DUAL;，看输出是否符合预期格式 - 注意
SCOPE=BOTH在 Oracle 12c+ 对NLS_DATE_FORMAT不支持，会报错ORA-02096: specified initialization parameter is not modifiable with this option - 如果用的是 Oracle RAC，得确保所有节点都从同一个 spfile 启动，否则可能部分节点用新格式、部分用旧格式
真正安全的做法是绕过 NLS_DATE_FORMAT 隐式转换
依赖全局日期格式本质上是把格式逻辑甩给数据库层，一旦环境迁移（比如从开发库复制参数到测试库）、或应用换了语言（Python cx_Oracle 默认用 en_US），就容易出问题。最稳的方式是代码里不传字符串，传 DATE 类型值。
- Java PreparedStatement 中用
setTimestamp(1, new Timestamp(...))，而不是setString(1, "2023-01-01") - PL/SQL 里写
INSERT INTO t(dt) VALUES (DATE '2023-01-01');，用日期字面量，不拼字符串 - SQL*Loader 控制文件里指定
DATE 'YYYY-MM-DD'显式解析，而不是靠NLS_DATE_FORMAT
改参数不是不行，但得清楚它只是补救手段；真正该花时间的地方，是把隐式转换点一个个找出来，换成显式类型处理。这点最容易被忽略，尤其当老系统里满屏 WHERE order_date > '2023-01-01' 的时候。
