判断两时间段是否重叠的核心逻辑是：NOT (end1

判断两个时间段是否重叠的通用逻辑

核心就一条：两个区间 [A, B] 和 [C, D]（假设左闭右闭）不重叠，当且仅当 B 或 <code>D 。反过来，只要不满足这个“不重叠”条件，就一定有交集——包括部分重叠、完全包含、端点相接（如 <code>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 做窗口分析，但判断两段交集仍推荐用基础比较

最稳妥、跨库一致的写法是：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

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 是冲突点，应视为重叠 → 用 判断不重叠：<code>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 小时。