判断两时间段是否重叠的核心逻辑是：NOT (end1 < start2 OR end2 < start1)；需确保时间字段为TIMESTAMP等正确类型、处理NULL、统一时区，并建立(start1, end1)复合索引以优化性能。
判断两个时间段是否重叠的通用逻辑
核心就一条：两个区间 [A, B] 和 [C, D]（假设左闭右闭）不重叠，当且仅当 B < C 或 D < A。反过来，只要不满足这个“不重叠”条件，就一定有交集——包括部分重叠、完全包含、端点相接（如 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 <= start2 OR end2 <= start1) - 若“事件结束瞬间下一个可立即开始”，则相接不冲突 → 保持
<即可 - MySQL 的
TIMESTAMP默认精确到秒，但若字段含毫秒（如TIME(3)），12:00:00.000和12:00:00.001就不会被=捕获，此时用<更安全
性能与索引建议
直接写 NOT (end1 < start2 OR end2 < start1) 会导致全表扫描，因为涉及多列组合条件。实际应用中应：
- 在
start1和end1上建复合索引（顺序建议为(start1, end1)），对查询WHERE start1 <= ? AND end1 >= ?类型更友好 - 避免在 WHERE 中对时间字段用函数，例如
DATE(start1) = '2024-01-01'会让索引失效 - 如果数据量大且查询频繁，可考虑物化交集标志（如加
has_overlap计算列 + 索引），但维护成本高，慎用
真正容易被忽略的是时区——start1 和 start2 必须落在同一时区下比较，否则 '2024-01-01 12:00+08' 和 '2024-01-01 12:00+00' 看似相同，实际差 8 小时。
