不能直接 group by 起止时间，因为重叠区间依赖前一行状态（当前 start_time ≤ 上一行 end_time 才合并），group by 无法表达这种动态断点逻辑；需用 lag() 识别断点、sum() over() 累计分组 id，并按 start_time asc, end_time asc 排序。

直接用 LAG() + SUM() OVER() 实现区间合并，无需自连接或递归，性能可控、逻辑清晰。

为什么不能直接 GROUP BY 起止时间？

因为重叠区间不是静态分组，而是动态依赖关系：第2行是否和第1行合并，取决于它的 start_time 是否 ≤ 第1行的 end_time。GROUP BY 无法表达这种“前一行状态影响当前行归属”的逻辑。

• 错误尝试：GROUP BY start_time, end_time —— 完全不解决重叠问题
• 错误尝试：GROUP BY FLOOR((start_time + end_time) / 2) —— 数值近似无业务意义，会错合或漏合
• 真正要识别的是“断点”：当 start_time > 上一行的 end_time 时，新组开始

LAG() 判断断点 + SUM() 累计分组 ID

核心是两步：先用 LAG(end_time) 拿到上组最大结束时间；再用条件标记是否新开组，最后累加生成组号。

Transfusion AI

一款面向室内设计场景的AI设计工具，帮助设计师围绕空间方案进行效果创作与视觉方案探索。

下载

• 必须按 start_time ASC, end_time ASC 排序，确保扫描顺序符合“左端点优先”逻辑
• LAG(end_time, 1, -999999) 中的默认值要足够小（如负数），避免首行判断出错
• 标记逻辑写成 CASE WHEN start_time ，然后 <code>SUM() OVER(... ORDER BY ... ROWS UNBOUNDED PRECEDING)
• 注意：PostgreSQL/MySQL 8.0+/SQL Server 均支持；SQLite 不支持窗口函数，需换方案

最终聚合：MIN(start_time) 和 MAX(end_time) 按组取极值

分组 ID 生成后，外层套一层 GROUP BY group_id 即可合并。但要注意边界细节：

• 如果原始数据含 NULL 时间，LAG() 可能返回 NULL，导致比较结果为 UNKNOWN，建议先 WHERE start_time IS NOT NULL AND end_time IS NOT NULL
• 严格重叠定义（如 [1,5] 和 [5,8] 是否算重叠）会影响 还是 <code> 的选择；业务要求“端点相接即合并”，就用 <code>
• 若需保留原 id 或其他字段（如来源标识），不能直接丢弃，得用 ARRAY_AGG(id)（PostgreSQL）或字符串拼接兜底

最易被忽略的是排序稳定性：当多个区间的 start_time 相同时，end_time ASC 是必须的，否则 LAG() 取到的可能是更短的 end_time，造成错误断点。实际数据里常有这种“同起点多终点”情况，别只测单条路径。