如何在SSRS报表存储过程中实现日历日/工作日双时间段查询？

嘿，这个需求我之前帮不少做SSRS报表的朋友处理过——先给你个明确的结论：用CASE语句在WHERE子句里实现是完全可行的，但算不算「最优」得看你的具体场景，比如数据量大小、索引情况这些。下面给你拆解几种常用方案，你可以按需选择：

这应该是你最先想到的写法，逻辑和SSRS的下拉参数对应得非常清晰，新手也能一眼看懂。假设你的参数是@DateType（可选值为'CalendarDay'或'BusinessDay'），还有用户选择的起始/结束日期@StartDate、@EndDate，时间字段是TransactionDateTime，写法大概是这样：

WHERE 
    CASE @DateType
        WHEN 'CalendarDay' THEN 
            -- 日历日：匹配完整24小时周期
            IIF(TransactionDateTime >= @StartDate AND TransactionDateTime < DATEADD(DAY, 1, @EndDate), 1, 0)
        WHEN 'BusinessDay' THEN
            -- 工作日：匹配营业时间，这里假设是9:00-18:00，按需调整
            IIF(TransactionDateTime >= DATEADD(HOUR, 9, CAST(@StartDate AS DATE)) 
                AND TransactionDateTime < DATEADD(HOUR, 18, CAST(@EndDate AS DATE)), 1, 0)
    END = 1

或者更简洁的写法（省去IIF）：

WHERE 
    CASE @DateType
        WHEN 'CalendarDay' THEN 
            TransactionDateTime >= @StartDate AND TransactionDateTime < DATEADD(DAY, 1, @EndDate)
        WHEN 'BusinessDay' THEN
            TransactionDateTime >= DATEADD(HOUR, 9, CAST(@StartDate AS DATE)) 
            AND TransactionDateTime < DATEADD(HOUR, 18, CAST(@EndDate AS DATE))
    END = 1

优缺点：

• 优点：逻辑直白，和SSRS参数的映射关系一目了然，后期维护成本低，不用改太多代码。
• 缺点：如果TransactionDateTime字段上建了索引，这种写法可能会让索引失效——因为数据库没办法提前预判CASE的执行结果，大概率会走全表扫描，数据量超过10万条的话，性能会明显下降。

如果你的报表数据量不小，或者对查询速度有要求，那直接用IF分支拆分不同的查询逻辑会更靠谱：

-- 先判断参数类型，走不同的查询分支
IF @DateType = 'CalendarDay'
BEGIN
    SELECT 
        -- 替换成你的实际报表字段
        TransactionID, TransactionAmount, TransactionDateTime
    FROM YourReportTable
    WHERE 
        TransactionDateTime >= @StartDate 
        AND TransactionDateTime < DATEADD(DAY, 1, @EndDate)
END
ELSE IF @DateType = 'BusinessDay'
BEGIN
    SELECT 
        -- 和上面一致的报表字段
        TransactionID, TransactionAmount, TransactionDateTime
    FROM YourReportTable
    WHERE 
        TransactionDateTime >= DATEADD(HOUR, 9, CAST(@StartDate AS DATE)) 
        AND TransactionDateTime < DATEADD(HOUR, 18, CAST(@EndDate AS DATE))
END

优缺点：

• 优点：每个分支的WHERE条件都是「可搜索参数（sargable）」，数据库能直接利用TransactionDateTime上的索引，大数据量下性能提升非常明显。
• 缺点：如果你的查询逻辑很复杂（比如有多个JOIN、复杂的字段计算），会出现代码重复，后期修改的时候要同时改两个分支，容易漏改。

要是不想重复写代码，又想保留索引的性能优势，动态SQL就是个不错的折中选择：

DECLARE @WhereClause NVARCHAR(MAX)
DECLARE @FullSQL NVARCHAR(MAX)

-- 根据参数拼接WHERE条件
SET @WhereClause = CASE @DateType
    WHEN 'CalendarDay' THEN 
        N'TransactionDateTime >= @StartDate AND TransactionDateTime < DATEADD(DAY, 1, @EndDate)'
    WHEN 'BusinessDay' THEN
        N'TransactionDateTime >= DATEADD(HOUR, 9, CAST(@StartDate AS DATE)) AND TransactionDateTime < DATEADD(HOUR, 18, CAST(@EndDate AS DATE))'
END

-- 拼接完整SQL语句
SET @FullSQL = N'
SELECT 
    TransactionID, TransactionAmount, TransactionDateTime
FROM YourReportTable
WHERE ' + @WhereClause

-- 用sp_executesql传递参数，绝对不能直接拼接参数值！
EXEC sp_executesql @FullSQL, 
    N'@StartDate DATETIME, @EndDate DATETIME',
    @StartDate = @StartDate, @EndDate = @EndDate

优缺点：

• 优点：既避免了代码重复，又能让每个分支的条件用上索引，性能和IF分支差不多。
• 缺点：动态SQL的可读性稍差，而且一定要注意用sp_executesql传参数，绝对不能把@StartDate这类参数直接拼进SQL里，不然会有SQL注入的风险。

• 如果报表数据量不大（比如几万条以内），直接用CASE写法就行，简单省心；
• 如果数据量大或者对性能要求高，优先选IF分支或者动态SQL；
• 另外，要是你的工作日规则比较复杂（比如有节假日、不同门店营业时间不同），建议单独建一个工作日日历表，查询的时候关联这个表，比硬写时间范围灵活得多。

内容的提问来源于stack exchange，提问作者Matt Johnson