两个时间区间重叠的充要条件是a.start < b.end 且 b.start < a.end；该逻辑覆盖所有重叠情形（含包含、相切），比仅判断端点相等或单向包含更完备，且利于B-tree索引优化查询性能。
为什么 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.end_time AND a.end_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 其实存的是日期而非时间戳。
