典型错误是直接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) <h3>MySQL 8.0+ 中 <code>ROW_NUMBER()</code> 的误用陷阱</h3><p>有人试图用 <code>ROW_NUMBER() - ROW_NUMBER() OVER (PARTITION BY ...)</code> 做差值分组，但重叠合并不满足“等差分组”前提——因为重叠关系不具备传递性（A 与 B 重叠、B 与 C 重叠，不代表 A 与 C 重叠），强行套用会导致合并过度。</p><p>例如数据：<code>(1,5), (2,3), (4,6), (7,9)</code>。若按 <code>start_time</code> 和 <code>end_time</code> 分别排序做差，可能把 <code>(1,5)</code> 和 <code>(7,9)</code> 错误归入同一组。</p><p>务必避免以下写法：</p><pre class="brush:php;toolbar:false;">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 条件里精确表达。
