判断两时间段是否重叠的核心逻辑是:NOT (end1
判断两个时间段是否重叠的通用逻辑
核心就一条:两个区间
[A, B]和[C, D](假设左闭右闭)不重叠,当且仅当B 或D 。反过来,只要不满足这个“不重叠”条件,就一定有交集——包括部分重叠、完全包含、端点相接(如B = C)等所有情况。注意:sql 中时间比较默认按字典序,但必须确保字段类型是
timestamp、dateTIME或带时区的等价类型;用char或VARCHAR存时间字符串会出错,尤其跨日或带毫秒时。mysql / postgresql / SQL Server 中的写法差异
主流数据库都支持标准比较操作符,但要注意 NULL 处理和边界语义:
- 如果任一时间字段可能为
NULL,直接比较会返回UNKNOWN,需显式排除:WHERE start1 IS NOT NULL AND end1 IS NOT NULL AND start2 IS NOT NULL AND end2 IS NOT NULL- PostgreSQL 支持
OVERLAPS操作符(如(start1, end1) OVERLAPS (start2, end2)),但要求两个参数都是(start, end)元组,且自动处理开闭性(左闭右开),行为与手写逻辑略有不同- SQL Server 2016+ 可用
DATEADD配合LEAD做窗口分析,但判断两段交集仍推荐用基础比较最稳妥、跨库一致的写法是:
WHERE NOT (end1 < start2 OR end2 < start1)常见错误:端点相等到底算不算重叠?
比如
event1: [2024-01-01 10:00, 2024-01-01 12:00]和event2: [2024-01-01 12:00, 2024-01-01 14:00]—— 端点12:00相接。是否算交集取决于业务定义:
- 若“同一时刻只能有一个事件”,则
12:00是冲突点,应视为重叠 → 用判断不重叠:NOT (end1- 若“事件结束瞬间下一个可立即开始”,则相接不冲突 → 保持
即可- MySQL 的
TIMESTAMP默认精确到秒,但若字段含毫秒(如TIME(3)),12:00:00.000和12:00:00.001就不会被=捕获,此时用更安全性能与索引建议
直接写
NOT (end1 会导致全表扫描,因为涉及多列组合条件。实际应用中应:
- 在
start1和end1上建复合索引(顺序建议为(start1, end1)),对查询WHERE start1 = ?类型更友好- 避免在 WHERE 中对时间字段用函数,例如
DATE(start1) = '2024-01-01'会让索引失效- 如果数据量大且查询频繁,可考虑物化交集标志(如加
has_overlap计算列 + 索引),但维护成本高,慎用真正容易被忽略的是时区——
start1和start2必须落在同一时区下比较,否则'2024-01-01 12:00+08'和'2024-01-01 12:00+00'看似相同,实际差 8 小时。
