正确做法是用 not exists 判断无重叠：if not exists (select 1 from events e where not (e.end_time @end)) begin insert... end；索引须建为 create index idx_events_period on events (start_time, end_time)。
用 NOT (end1
直接写 start1 = start2 看似直观，但容易漏掉端点相接是否算冲突的业务逻辑分歧。T-SQL 中更推荐用“反向定义”：先写出**不重叠**的两种情形（A 完全在 B 左侧，或 A 完全在 B 右侧），再取反。即：NOT (end1 。这个表达式覆盖全部重叠场景（交叉、包含、端点相接），且与 SQL Server 的 NULL 处理行为兼容——只要任一字段为 NULL，整个条件返回 UNKNOWN，不会误判为重叠。
常见错误现象：
- 用
BETWEEN写成start2 BETWEEN start1 AND end1：漏掉start2 但 <code>end2 > start1的交叉情况 - 只写
start1 ：会把大量左表记录和右表末尾记录强行匹配，产生笛卡尔积倾向
LEFT JOIN + 重叠条件查“无冲突”必须改用 NOT EXISTS
想在存储过程中找出“不与任何现有记录重叠的新时间段”，很多人写：
SELECT @newId FROM @input t LEFT JOIN events e ON NOT (e.end_time t.end_time) WHERE e.id IS NULL
这语句在 events 表为空时，e.id IS NULL 恒成立，导致所有输入都被判定为“无冲突”，严重逻辑错误。
正确做法是用 NOT EXISTS 显式表达“不存在任何重叠记录”：
IF NOT EXISTS ( SELECT 1 FROM events e WHERE NOT (e.end_time @end) ) BEGIN INSERT INTO events (start_time, end_time, ...) VALUES (@start, @end, ...); END
这样即使 events 为空，子查询返回空集，NOT EXISTS 为 TRUE，逻辑才自洽。
索引必须是 (start_time, end_time) 复合索引，单列无效
T-SQL 优化器对区间重叠条件无法有效利用单列索引。start_time 上的索引只能加速 start_time 类查询，但重叠判断涉及两个方向的边界（<code>end_time 和 <code>start_time > end2），必须靠复合索引剪枝。
执行以下建索引语句：
CREATE INDEX idx_events_period ON events (start_time, end_time);
注意顺序：按 start_time 升序排列后，再按 end_time 排，能让 SQL Server 在扫描到某个 start_time 范围后，快速跳过明显不满足 end_time 的行。实测在 10 万行数据上，相比无索引可提速 50 倍以上。
避免踩坑：
- 不要建
(end_time, start_time)——顺序颠倒后范围扫描效率骤降 - 不要对字段加函数，如
DATE(start_time)，会导致索引完全失效 - 字段类型必须一致：如果参数传的是
datetime2(0)，表字段也得是datetime2，混用datetime可能触发隐式转换
存储过程里要显式处理 NULL 和时区对齐
时间字段为 NULL 时，NOT (end1 整体为 UNKNOWN，WHERE 不会选中该行——这本身是安全的，但容易让人误以为“没查到就是没重叠”。建议在存储过程开头就做显式校验：
IF @start IS NULL OR @end IS NULL THROW 50000, 'start_time and end_time must not be NULL', 1;
时区问题更隐蔽：SQL Server 默认按服务器时区解析字面量，但应用层传来的 datetimeoffset 若未统一转为目标时区（如 UTC），比较结果可能错位。稳妥做法是在存储过程入参用 datetimeoffset 类型，并在比较前统一转换：
DECLARE @startUtc datetime2 = TODATETIMEOFFSET(@start, '+00:00');
真正难处理的不是语法，而是当同一业务流程分散在多个存储过程、触发器、甚至外部服务中时，各处对“端点相接是否算冲突”的定义是否一致——这个一致性必须靠文档+单元测试兜底，不能只靠 SQL 一行代码。
