sql server中应避免while循环逐天判断，而用递归cte或数字表一次性生成日期序列并批量关联节假日表；需统一set datefirst 1、holiday_date字段用date类型并建索引、按天切片计算工作时段交集。
SQL Server里别用WHILE循环逐天判断
一查跨度超过3个月，WHILE 循环就会明显变慢；跨度超1年，常因单行查表（如 EXISTS(SELECT 1 FROM dbo.Holidays WHERE holiday_date = @d)）触发上千次IO，函数超时或拖垮连接池。
真正可行的路径是：一次性生成日期序列，再批量关联节假日表。核心不是“怎么循环”，而是“怎么避免循环”。
- 用递归CTE或数字表（如
dbo.Numbers）生成范围内的所有DATE值，别依赖master..spt_values（仅限开发环境） -
WHERE n.n BETWEEN 0 AND DATEDIFF(DAY, @start_date, @end_date)是安全边界，但注意@end_date是否含时分秒——建议先CAST(@end_date AS DATE) - 生成后立刻
LEFT JOIN dbo.Holidays ON dt = h.holiday_date，别在循环里反复查
必须显式控制 SET DATEFIRST 再算周末
DATEPART(WEEKDAY, d.dt) 返回值完全取决于会话级设置：SET DATEFIRST 7（默认）时周日=1、周六=7；设成 SET DATEFIRST 1 时周一=1、周日=7。硬写 NOT IN (1,7) 在不同环境会漏判周六或周日。
最稳妥的做法是在存储过程开头统一重置：
SET DATEFIRST 1; -- 强制周一=1，后续用 NOT IN (6,7) 判断周末
或者用更稳定但稍绕的方式：
AND (DATEPART(WEEKDAY, d.dt) + @@DATEFIRST - 2) % 7 NOT IN (5,6)
但后者调试困难，不推荐用于生产函数。
节假日表字段类型和索引不能错
dbo.Holidays 表的 holiday_date 字段必须是 DATE 类型，不是 DATETIME 或字符串。否则 JOIN d.dt = h.holiday_date 可能触发隐式转换，导致索引失效或结果偏差。
is_workday BIT 用来标记调休补班日（如周日上班），值为 1 表示该日算工作日，0 表示纯放假。
- 务必在
holiday_date上建索引：CREATE INDEX IX_Holidays_date ON dbo.Holidays(holiday_date); - 别用
CASE WHEN @date IN ('2024-01-28', '2024-01-29')硬编码——每年国务院通知一出就得改代码，没人敢动 - 日历数据建议提前生成3–5年，并人工校对调休安排（比如2026年中秋调休是9月13日周六上班）
工作时段交集计算要按天切片，不能只算天数
如果业务要求只计 08:00–20:00，那必须对每一天单独算有效分钟数，再 SUM。直接 DATEDIFF(HOUR, @start_datetime, @end_datetime) 会把非工作时间全包进去，结果严重偏高。
关键步骤是为每个 dt 计算当天合法起止时间与输入区间的交集：
work_start = CAST(dt AS DATETIME) + '08:00'<br>work_end = CAST(dt AS DATETIME) + '20:00'<br>actual_start = CASE WHEN @start_datetime > work_start THEN @start_datetime ELSE work_start END<br>actual_end = CASE WHEN @end_datetime <p>最后过滤掉无效段：<code>WHERE actual_start ，再 <code>SUM(DATEDIFF(MINUTE, actual_start, actual_end)) / 60.0</code> 得到小时数。</code></p><p>容易被忽略的是：<code>@start_datetime</code> 和 <code>@end_datetime</code> 必须是同一时区（建议全转为 UTC 存储），否则跨时区业务在凌晨时段可能被错判为“前一天”或“后一天”，导致整日漏算。</p>
