row_number()在拉链表中必须配合start_time升序和end_time降序显式排序，否则序号失去时序意义；单层无法区分有效态，需结合标记与多层窗口；它仅暴露时间重叠/断层问题，不修复数据；性能依赖(business_key, start_time)复合索引。
ROW_NUMBER() 在拉链表中必须配合时间字段排序
不规则拉链表的典型问题是：同一主键（如 user_id）存在多条记录，start_time 和 end_time 有重叠、缺失或乱序。直接用 ROW_NUMBER() 不会自动识别业务逻辑，它只按指定列排序后硬编号。如果漏掉 ORDER BY start_time, end_time DESC 这类关键排序，生成的序号就失去时序意义，后续取最新/上一条就会错。
实操建议：
- 始终在
ROW_NUMBER()的OVER()子句中显式声明时间排序，优先用start_time升序，再用end_time降序（处理同起点多终点情况） - 避免仅按
id或insert_time排序——这些字段不反映业务生效顺序 - 若源数据时间精度不一致（如部分到秒、部分到天），先用
CAST或DATE_TRUNC对齐，否则排序结果不稳定
用 ROW_NUMBER() 标记“当前有效”和“历史版本”需两层窗口
单靠一层 ROW_NUMBER() 只能编号，无法区分哪条是当前有效记录（end_time = '9999-12-31' 或 NULL）或上一版。常见错误是写成 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY start_time DESC) 然后取 rn = 1，但这可能选出已失效的记录（比如某条记录 start_time 很大但 end_time 已过期）。
正确做法是分两步：
- 第一层：用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY start_time DESC)获取按起点倒序的序号 - 第二层：用
CASE WHEN end_time = '9999-12-31' THEN 1 ELSE 0 END标记有效态，再套一层MAX() OVER (PARTITION BY user_id)广播该标记 - 最终过滤时组合条件：
rn = 1 AND is_current = 1才是真正当前有效记录
处理时间断层或重叠时，ROW_NUMBER() 本身不修复数据，只暴露问题
ROW_NUMBER() 是观察工具，不是清洗工具。当发现同一 user_id 的相邻记录出现 next.start_time （重叠）或 <code>next.start_time > current.end_time + INTERVAL '1 day'（断层）时，序号只会忠实地把它们编成 1、2、3……但不会报错或跳过。
这时要主动加校验逻辑：
- 用
LAG(end_time) OVER (PARTITION BY user_id ORDER BY start_time)拿到上一条的end_time - 构造布尔列：
is_overlap = (start_time - 在 WHERE 中筛出
is_overlap = true的行，人工确认是否应合并或修正 - 注意：PostgreSQL 需用
COALESCE(LAG(...), '-infinity')处理首行 NULL，否则比较结果为 UNKNOWN
性能敏感场景下，ROW_NUMBER() 的分区键必须有索引支撑
对千万级拉链表执行 ROW_NUMBER() OVER (PARTITION BY business_key ORDER BY start_time)，若 (business_key, start_time) 无复合索引，全表扫描+排序极易触发磁盘临时文件，查询从秒级升至分钟级。
优化要点：
- 建索引优先级：先
business_key，再start_time；若常查特定业务状态，可加入status作为第三列 - 避免在
OVER()中使用函数表达式排序，如ORDER BY DATE(start_time)—— 会导致索引失效 - 在 Hive/Spark SQL 中，
DISTRIBUTE BY business_key SORT BY start_time比纯ROW_NUMBER()更可控，尤其数据倾斜时
真正麻烦的从来不是写对 ROW_NUMBER()，而是确认源数据里那些“看起来像时间”的字段，到底有没有被业务系统真实维护过。一个没被任何上游服务更新过的 end_time，再漂亮的序号也救不回来。
