Oracle无内置工作日差函数，可靠实现需用to_char(dt,'D','NLS_DATE_LANGUAGE=AMERICAN')固定周日=1/周六=7，显式查节假日表（建索引），并明确起止日是否包含。
PL/SQL里怎么写一个靠谱的workdays_between函数
直接说结论：不能只靠next_day或to_char(date, 'd')硬算，必须显式查节假日表+处理跨年边界。oracle没有内置“工作日差”函数，自己封装时最容易错的是把周六日逻辑写死在nls设置里，一换数据库语言就崩。
实操建议：
- 用
to_char(dt, 'D', 'NLS_DATE_LANGUAGE=AMERICAN')固定周日=1、周六=7，避免依赖会话NLS_TERRITORY - 节假日必须走表查询（比如
holidays表），别用硬编码数组——政策调整后得改代码，运维没法接受 - 起止日期是否包含当天？按业务定，但函数注释里必须写清：
INCLUSIVE = TRUE表示两端都算 - 示例骨架：
FUNCTION workdays_between(p_start DATE, p_end DATE) RETURN NUMBER IS v_cnt NUMBER := 0; BEGIN FOR d IN 0..TRUNC(p_end) - TRUNC(p_start) LOOP IF TO_CHAR(TRUNC(p_start) + d, 'D', 'NLS_DATE_LANGUAGE=AMERICAN') NOT IN ('1','7') AND NOT EXISTS (SELECT 1 FROM holidays h WHERE h.holiday_date = TRUNC(p_start) + d) THEN v_cnt := v_cnt + 1; END IF; END LOOP; RETURN v_cnt; END;
为什么next_day和last_day不适合算工作日差
这两个函数是日期偏移工具，不是逻辑判断工具。拿next_day(sysdate, 'SATURDAY')推周末再减，看似省事，实际埋了三个坑：
- 无法跳过连续多天节假日（比如国庆七天假），它只会跳到下一个周六，中间五天全被当成工作日
-
next_day受NLS_DATE_LANGUAGE影响极大，法语环境里'SATURDAY'直接报ORA-01846 - 性能差：每算一天都要调一次函数，上万行数据批量计算时CPU飙升
- 正确姿势是预生成日期序列（用
CONNECT BY LEVEL或递归WITH），再统一过滤，而不是逐个调next_day
节假日表设计和查询怎么不拖慢性能
每次算工作日都查一次holidays表，如果没索引或没分区，10万条记录下函数响应直接从毫秒变秒级。
实操建议：
- 给
holidays.holiday_date建B树索引，类型必须是DATE，别用VARCHAR2存'2024-01-01' - 如果系统要支持多国节假日，加
country_code字段，并在WHERE里明确指定，别留成可空字段让优化器放弃索引 - 避免在函数里写
SELECT COUNT(*) FROM holidays...——COUNT比EXISTS慢，且容易锁表；用EXISTS (SELECT NULL FROM holidays...)即可 - 如果节假日极少变动（比如每年只增10条），考虑用
RESULT_CACHE修饰函数，但注意它不感知表数据变更，需手动DBMS_RESULT_CACHE.FLUSH
遇到ORA-01843: not a valid month这类错误怎么快速定位
这错误90%不是日期格式问题，而是函数里拼错了NLS参数位置，或者传入了NULL日期没判空。
- 检查所有
TO_CHAR调用：第二个参数必须是格式模型，第三个才是NLS参数，写成TO_CHAR(d, 'NLS_DATE_LANGUAGE=AMERICAN', 'D')必报错 - 在函数开头加
IF p_start IS NULL OR p_end IS NULL THEN RETURN NULL; END IF;，别让NULL进循环 - 如果用了动态SQL（比如拼表名查不同国家节假日），
EXECUTE IMMEDIATE里字符串拼接漏了单引号，也会触发这个错误，用DBMS_OUTPUT.PUT_LINE打出来看实际SQL - 测试时故意传
DATE '0001-01-01'，Oracle对超范围日期报的也是ORA-01843，不是所有环境都开DATE校验
函数真正难的不是写出来，是让别人敢在生产报表里调用它——得扛住并发、跨时区、节假日突增、NLS漂移。这些细节不压平，上线后半夜电话就来了。
