典型错误是直接GROUP BY或MIN/MAX导致误合并，如[(1,3),(2,4),(6,8)]错成(1,8)；正确做法是用LAG()比较前段end_time与当前start_time，空隙处累加生成分组ID。
什么是重叠时间段合并的典型错误写法
直接用 GROUP BY 或普通聚合（如 MIN(start_time), MAX(end_time)）会漏掉中间断点或错误拉通——比如 [(1,3), (2,4), (6,8)] 被粗暴合成为 (1,8)，实际应拆成 (1,4) 和 (6,8)。窗口函数不是万能胶，关键在识别“何时该开启新组”。
核心思路是：把每个时间段看作一次“事件”，用 LAG() 找上一条记录的 end_time，判断是否小于当前 start_time；若小于，说明有空隙，需要新开一个连续段。
用 LAG() + 累计求和构造分组 ID
这是最稳定、兼容性最好的方案，PostgreSQL / MySQL 8.0+ / SQL Server / Oracle 都支持。
步骤如下：
- 先按
start_time排序，确保时间线有序 - 用
LAG(end_time) OVER (ORDER BY start_time)获取前一条的结束时间 - 用
CASE WHEN LAG(end_time) 标记“断点” - 对断点做
SUM() OVER (ORDER BY start_time ROWS UNBOUNDED PRECEDING)得到连续段 ID
SELECT
MIN(start_time) AS merged_start,
MAX(end_time) AS merged_end
FROM (
SELECT *,
SUM(is_new_group) OVER (ORDER BY start_time ROWS UNBOUNDED PRECEDING) AS grp_id
FROM (
SELECT *,
CASE WHEN LAG(end_time) OVER (ORDER BY start_time) < start_time
THEN 1 ELSE 0 END AS is_new_group
FROM time_ranges
) t
) t2
GROUP BY grp_id;MySQL 8.0+ 中 ROW_NUMBER() 的误用陷阱
有人试图用 ROW_NUMBER() - ROW_NUMBER() OVER (PARTITION BY ...) 做差值分组，但重叠合并不满足“等差分组”前提——因为重叠关系不具备传递性（A 与 B 重叠、B 与 C 重叠，不代表 A 与 C 重叠），强行套用会导致合并过度。
例如数据：(1,5), (2,3), (4,6), (7,9)。若按 start_time 和 end_time 分别排序做差，可能把 (1,5) 和 (7,9) 错误归入同一组。
务必避免以下写法：
SELECT MIN(start_time), MAX(end_time)
FROM (
SELECT *,
ROW_NUMBER() OVER (ORDER BY start_time)
- ROW_NUMBER() OVER (ORDER BY end_time) AS grp
FROM time_ranges
) t
GROUP BY grp;性能与边界情况提醒
大表（百万级以上）跑这个逻辑时，ORDER BY start_time 的索引必不可少，否则 LAG() 窗口会触发全表排序，极慢。
还需注意三个易忽略点：
-
start_time和end_time为NULL时，LAG()返回NULL，而NULL 结果为 <code>UNKNOWN，需显式处理，例如：LAG(end_time) OVER (...) IS NULL OR LAG(end_time) - 闭区间 vs 半开区间：若
[1,3]和[3,5]视为可合并（端点相接），条件要改成LAG(end_time) - 存在完全嵌套（如
(1,10), (2,3), (4,5)）不影响结果，因为MIN/MAX在分组后自然覆盖
真正卡住人的往往不是语法，而是没想清楚“断点”的定义方式——它取决于你的业务语义：是严格不重叠？允许相接？还是容忍微小间隙（如 1 秒）？这些都得在 CASE 条件里精确表达。
