直接用ON t1.start = t2.start会出错，因其仅判断起点相等而忽略重叠本质，未排除自匹配（需加t1.id != t2.id），易致冗余或笛卡尔积；且无索引时引发全表扫描，性能断崖下降。
为什么直接用 ON t1.start = t2.start 会出错？
这个条件本身逻辑正确，但容易漏掉关键约束：它只判断重叠，不保证「谁在左、谁在右」，也不排除自身与自身的错误匹配（尤其当表自连接且时间区间相同时）。更严重的是，如果没加 WHERE 过滤或 AND t1.id != t2.id，可能返回大量冗余行甚至笛卡尔爆炸——特别是当一张表有数千条区间记录时，性能会断崖式下降。
实操建议：
- 始终显式排除自匹配：
ON ... AND t1.id != t2.id（假设主键是id） - 若只需找「被覆盖」关系（如 t2 完全落在 t1 内），改用
t1.start = t2.end，避免模糊重叠 - 在 JOIN 前先对区间字段加索引：
CREATE INDEX idx_intervals ON table_name(start, end)，否则全表扫描不可避免
如何用 LEFT JOIN 找出「未被任何区间覆盖」的记录？
这是典型“存在性否定”问题。不能写 WHERE NOT (t1.start = t2.start)，因为 LEFT JOIN 后 t2.* 字段为 NULL，直接比较会因 NULL 传播全部返回 false。
正确写法是把重叠判断放进 ON，再在 WHERE 中检查右表是否为空：
SELECT t1.* FROM intervals t1 LEFT JOIN intervals t2 ON t1.id != t2.id AND t1.start <= t2.end AND t1.end >= t2.start WHERE t2.id IS NULL;
注意点：
-
t2.id IS NULL是唯一可靠的“无匹配”判断方式；t2.start IS NULL不安全，因为字段可能允许 NULL - 如果 t2 表有 WHERE 条件（比如只考虑 active=1 的区间），必须移到
ON里，否则会把 LEFT JOIN 变成 INNER JOIN - MySQL 8.0+ 或 PostgreSQL 可用
NOT EXISTS替代，语义更清晰且通常更快
PostgreSQL 中用 tsrange 能省多少事？
原生区间类型让重叠判断从 4 个比较变成一个操作符：t1.range && t2.range。不仅简洁，还自动处理边界包含逻辑（如 [start, end] vs [start, end)），并支持 GIST 索引加速。
建表和查询示例：
CREATE TABLE events ( id SERIAL PRIMARY KEY, range TSRANGE ); CREATE INDEX idx_events_range ON events USING GIST(range); <p>SELECT e1.id, e2.id FROM events e1 JOIN events e2 ON e1.id != e2.id AND e1.range && e2.range;
坑点：
-
tsrange('2023-01-01', '2023-01-05')默认是左闭右开[ )，要改成闭区间得显式写tsrange('2023-01-01', '2023-01-05', '[]') - MySQL 没有等价类型，别试图用 JSON 或字符串模拟——索引失效、无法用操作符、边界逻辑全得手写
- 即使用了
tsrange，仍需id != id防自匹配，操作符不管这个
当区间数量大到 JOIN 卡死，还能怎么破？
JOIN 在 N² 复杂度下必然崩，尤其 N > 10⁴。这时得跳出 SQL 关联思维，改用窗口函数或物化路径预处理。
一种稳定解法：按起点排序，用 LEAD() 找下一个区间的起点，再判断当前区间是否被「下一个起点前的某个区间」覆盖：
WITH ordered AS (
SELECT id, start, end,
LEAD(start) OVER (ORDER BY start) AS next_start
FROM intervals
)
SELECT o1.*
FROM ordered o1
WHERE o1.end < o1.next_start;这只能检测「孤立区间」，但比暴力 JOIN 快两个数量级。真正通用的方案是：
- 用 Python/Go 写一次性的区间合并脚本，输出「最小覆盖集」，再回写数据库供 JOIN 使用
- 在应用层维护一个内存中的区间树（如
intervaltree库），查重叠是 O(log n + m)，m 是结果数 - 接受近似解：对时间字段做分桶（如按小时），先粗筛桶交集，再在桶内细查——适合实时性要求不苛刻的场景
最常被忽略的一点：业务上是否真的需要精确重叠？很多时候“同一天内有交集”就足够，这时用 DATE(start) = DATE(end) 加索引，比处理任意精度时间区间简单得多。
