如何在SQL中对时间范围重叠数据执行非等值JOIN匹配？-SQL-PHP中文网

两个时间区间重叠的充要条件是a.start

为什么 ON a.start = b.start 是重叠判断的核心条件

两个时间区间 [a.start, a.end] 和 [b.start, b.end] 发生重叠，当且仅当：a 的起始不晚于 b 的结束，且 a 的结束不早于 b 的起始。这个逻辑比「相等」或「包含」更基础，也更容易被索引利用（尤其当字段有 B-tree 索引时）。漏掉任一端都会漏数据——比如只写 a.start ，会把 a 完全在 b 左侧（但挨着）的记录也拉进来。

常见错误现象：ON a.start BETWEEN b.start AND b.end 或 ON b.start BETWEEN a.start AND a.end，这两种写法都隐含单向覆盖假设，无法捕获 a 完全包裹 b 或 b 完全包裹 a 的情况。

必须同时检查两端边界，缺一不可

注意字段是否为 NULL：如果任意端点可能为空，需提前用 COALESCE 或 WHERE 过滤，否则整行会被丢弃（SQL 中 NULL 参与比较结果为 UNKNOWN）

时间精度要一致：比如一边是 TIMESTAMP，一边是 DATE，MySQL 可能自动补零，但 PostgreSQL 会报错或静默截断

如何避免笛卡尔爆炸和性能崩盘

非等值 JOIN 天然容易触发全表扫描，尤其当两张表都很大时。数据库优化器对 /<code>>= 条件的支持远不如等值条件，所以不能依赖它自动选对驱动表。

优先让小表做驱动表（即 FROM small_table a JOIN large_table b），减少外层循环次数

确保用于比较的字段（start 和 end）都有单独索引或联合索引；例如在 MySQL 中，(start, end) 联合索引对 a.start 效果有限，但 <code>INDEX(end) 和 INDEX(start) 分别建效果更好

PostgreSQL 用户可考虑用 RANGE 类型 + GiST 索引，配合 && 操作符，性能提升显著

加 LIMIT 测试前先加 EXPLAIN ANALYZE，观察实际是否走了索引、是否出现 Materialize 或大量 Hash Join

不同数据库对开闭区间的处理差异

业务中常遇到「会议从 9:00 开始，10:00 结束」——这到底是 [9:00, 10:00) 还是 [9:00, 10:00]？SQL 自身不定义区间语义，全靠你写条件时对齐。

若约定为左闭右开（推荐），则重叠条件应为：a.start b.start（注意是 和 <code>>）

若约定为左闭右闭，则用标准写法：a.start = b.start

MySQL 的 BETWEEN 是闭区间，但 INTERVAL 函数默认按秒/微秒对齐，容易因精度丢失导致边界误判

SQL Server 的 DATETIME2 默认精度为 100ns，而 DATETIME 只有 3.33ms，混用可能让本该重叠的两条记录判定为不重叠

真实场景下的典型写法与避坑点

比如查「每个工单与其冲突的其他工单」，表 orders 含 id、start_time、end_time：
SELECT a.id AS order_id, b.id AS conflict_id
FROM orders a
JOIN orders b ON a.id != b.id
  AND a.start_time = b.start_time;
这里最易忽略的是 a.id != b.id —— 不加这句，每条记录都会和自己匹配一次。另外，若业务要求「至少重叠 5 分钟」，不能简单改成 a.end_time - a.start_time >= '00:05'，而应写成：GREATEST(a.start_time, b.start_time) （PostgreSQL）或对应数据库的时间减法函数。

复杂点往往不在逻辑本身，而在时间类型隐式转换、时区未统一、以及前端传入的时间字符串未被正确解析为带精度的 timestamp。这些地方出问题，查半天才发现不是 JOIN 写错了，而是 end_time 其实存的是日期而非时间戳。