row_number()必须显式order by且列类型需为date/datetime，分区场景须用partition by；lag/lead需配合partition by和null过滤；嵌套查询是使用窗口函数进行聚合的必要结构。
ROW_NUMBER() 差值法必须显式 ORDER BY
SQL Server 中 ROW_NUMBER() 不加 ORDER BY 会报错，但更隐蔽的问题是：即使写了 ORDER BY，若字段类型不一致（比如用 VARCHAR 存日期却按字符串排序），结果就完全错乱。连续的 '2026-01-10' 和 '2026-01-2' 按字符串排会变成 '2026-01-10' 在前，导致差值崩坏。
实操建议：
- 所有
ROW_NUMBER()必须带ORDER BY date_column，且该列类型为DATE或DATETIME - 若原始列是字符串，先用
CONVERT(DATE, date_str)转换再排序 - 分区场景（如按用户分组）必须写
PARTITION BY user_id ORDER BY login_date，漏掉PARTITION BY就变成全局编号，分组失效
LAG() 识别时间断点比差值法更直接
当“连续”定义不是严格相邻日期，而是“间隔 ≤ 1 天”，ROW_NUMBER() 差值法会把 '2026-01-01' 和 '2026-01-03' 当作断点（因为缺 '2026-01-02'），但业务上可能接受 1 天断档。这时必须用 LAG() 计算实际时间差。
常见错误现象：LAG(date_col) 没配合 PARTITION BY，导致跨用户拉取前一行时间，生成错误断点。
实操建议：
- 用
LAG(login_date) OVER (PARTITION BY user_id ORDER BY login_date)获取同一用户的上一次登录时间 - 再用
DATEDIFF(day, prev_date, login_date) > 1标记新岛屿起点 - 避免用
GETDATE()或函数包裹列参与排序——SQL Server 优化器可能跳过索引
LEAD() 提取缝隙时要过滤 NULL 结尾行
用 LEAD(island_end) 算缝隙起始，最后一行的 LEAD() 必然返回 NULL，如果没过滤，会生成一条 Gap start = island_end + 1, Gap end = NULL 的无效记录，下游处理容易报错。
性能影响：在千万级表上，LEAD() 本身开销不大，但若外层再套聚合或 JOIN，未加 WHERE lead_col IS NOT NULL 会让执行计划多扫一遍 NULL 行。
实操建议：
-
LEAD(island_end) OVER (ORDER BY island_end)后立即加WHERE lead_island_end IS NOT NULL - 缝隙计算用
island_end + 1作为 gap_start，lead_island_end - 1作为 gap_end - 若原始数据含时间戳，单位必须统一：用
DATEADD(second, 1, island_end)还是DATEADD(day, 1, island_end)，取决于业务定义的“连续”粒度
嵌套查询不是可选，而是必须结构
窗口函数只能生成中间标识，不能直接聚合。想得到每个岛屿的 MIN(date) 和 MAX(date)，必须把 island_id 放进子查询，外层再 GROUP BY island_id。试图在单层查询里同时写 ROW_NUMBER() 和 GROUP BY 会触发 SQL Server 报错：“窗口函数不能出现在 GROUP BY 子句中”。
容易踩的坑：
- 子查询 alias 没定义，外层引用时报
Invalid column name -
island_id没放进外层GROUP BY，导致聚合结果被压缩成单行 - 忘记对
island_id加索引——虽然它只是计算列，但大表分组时仍显著影响 tempdb 使用量
真正麻烦的是时间粒度混用和重叠区间，那已经超出窗口函数能力范围，得先做区间归一化。
