不能直接 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) 拿到上组最大结束时间；再用条件标记是否新开组，最后累加生成组号。
- 必须按
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，造成错误断点。实际数据里常有这种“同起点多终点”情况，别只测单条路径。
