基于多组起止日期对动态构建存储过程SQL Between查询条件的实现咨询

最优实现方向：用表值参数传递日期对集合 #

这是当前场景下鲁棒性、性能、可维护性综合最高的方案，完全不需要自己写字符串拆分、动态拼条件的逻辑：

• 首先在数据库层面提前创建一次自定义表类型，用来结构化存储传入的start/end日期对：

-- 该类型只需创建一次，可被所有存储过程复用
CREATE TYPE DateRangeTableType AS TABLE(
    RangeStart DATE NOT NULL,
    RangeEnd DATE NOT NULL,
    -- 内置校验规则，从入参层面避免开始日期晚于结束日期的非法值
    CONSTRAINT CK_ValidRange CHECK (RangeStart <= RangeEnd)
)

• 存储过程定义时直接把上述自定义类型作为只读入参，核心查询用EXISTS关联匹配，等价于多组OR连接的Between过滤效果：

CREATE PROCEDURE GetBookingsByDateRanges
    @DateRanges DateRangeTableType READONLY
AS
BEGIN
    SET NOCOUNT ON;

    SELECT b.*
    FROM Booking b
    WHERE EXISTS (
        SELECT 1
        FROM @DateRanges r
        -- 用>=和<的写法替代BETWEEN，避免datetime带时分秒的边界漏查问题
        WHERE b.FromDate >= r.RangeStart
          AND b.FromDate < DATEADD(DAY, 1, r.RangeEnd)
    )
END

这个方案的核心优势：

• 无字符串解析逻辑，所有类型校验、结构对齐由数据库引擎完成，没有格式错配、分隔符转义、日期值配对错位的问题
• 全程参数化查询，没有动态拼SQL带来的注入风险，执行计划稳定可复用
• 当日期对数量较多时，优化器可以自动选择最优执行路径，不会像硬拼一长串OR条件那样出现执行计划性能骤降的问题

前期梳理的两个思路的问题与修正 #

1. 双层分隔字符串+两次string_split的实现 #

这个思路的鲁棒性差是天生的：本质是把结构化的日期对硬编码为非结构化字符串，需要自己处理日期格式不统一、分隔符被特殊字符转义、拆分后start/end行错位、空值校验等一堆兜底逻辑，长期维护成本极高。
如果因为老系统限制没法用表值参数，至少不要自造分隔字符串格式，可以改用标准JSON格式传参，通过OPENJSON直接解析成规整的两列行集，稳定性会比自造双层分隔符好很多，但整体体验仍然不如原生表值参数。

2. 解析日期值写入临时表、动态生成Between条件的实现 #

这个思路最大的坑是会滑向动态SQL路径：需要把临时表的每一行拼接成OR FromDate Between xxx And yyy的字符串，不仅要处理SQL注入校验，还会因为条件拼接的文本变化导致存储过程无法复用执行计划。
实际上只要日期对已经解析存入表变量/临时表，完全不需要动态拼Where条件，直接套用前面提到的EXISTS关联写法就能实现完全一致的过滤效果，没有动态SQL的所有弊端。

落地注意事项 #

• 不要为了还原参考逻辑里的多组OR Between效果硬拼条件串：当日期对数量超过10个，长串OR条件会大幅增加优化器的计算负担，关联匹配的写法性能会远高于硬拼OR
• 记得给Booking表的FromDate字段建立合适的索引，否则不管用哪种实现方式查询性能都没有基础保障
• 处理datetime类型的日期边界时，尽量用>= 开始日期 And < 结束日期加1天的写法，比BETWEEN更不容易漏掉结束日期当天带时分秒的记录

内容的提问来源于stack exchange，提问作者Neil Thompson