拉链表是scd type 2的一种实现，通过start_date和end_date标记每条记录的有效时间区间，支持历史状态追溯；不能直接用普通等值join，因其会导致同一主键的多个时间版本交叉匹配，产生笛卡尔积，必须引入时间条件（如between）定位指定时刻的有效版本后再关联。
什么是拉链表，为什么不能直接用普通 JOIN 比对
拉链表（Slowly Changing Dimension Type 2）本质是靠 start_date 和 end_date 划分历史版本，同一主键可能有多个时间区间记录。直接用 ON a.id = b.id 的等值 JOIN 会把所有版本全匹配上，产生笛卡尔积——比如 A 表有 3 条历史记录、B 表有 4 条，JOIN 后就蹦出 12 行，根本没法判断“哪一版对哪一版”。必须把时间维度纳入关联逻辑。
用 BETWEEN + 子查询定位“当前有效版本”再 JOIN
最常用也最稳妥的做法：先各自找出某时刻（比如比对基准日 '2024-06-01'）下有效的那条记录，再基于主键等值 JOIN。关键在 WHERE 条件里加时间约束：
SELECT a.id, a.name AS a_name, b.name AS b_name FROM dim_user_a a JOIN dim_user_b b ON a.id = b.id WHERE '2024-06-01' BETWEEN a.start_date AND a.end_date AND '2024-06-01' BETWEEN b.start_date AND b.end_date;
注意点：
-
end_date通常设为'9999-12-31'表示“至今有效”，所以BETWEEN能覆盖；如果用NULL表示未结束，就得改写成'2024-06-01' >= a.start_date AND (a.end_date IS NULL OR '2024-06-01' - 如果拉链表没建
(id, start_date)或(id, start_date, end_date)复合索引，这个查询会很慢——时间范围扫描代价高 - 基准日必须明确，不能模糊写成
CURRENT_DATE（除非你真想比“今天”的状态）
用 LEFT JOIN + 时间重叠判断找“状态变更点”
要查哪些记录在 A 表和 B 表中存在时间重叠但属性不同（即发生过变更），就得放弃“单点快照”，转而检测区间交集：
SELECT a.id, a.start_date, a.end_date, b.start_date, b.end_date FROM dim_user_a a LEFT JOIN dim_user_b b ON a.id = b.id AND a.start_date = b.start_date WHERE a.name != COALESCE(b.name, '') OR b.id IS NULL;
这里 a.start_date = b.start_date 是标准的区间重叠判断（避免用 BETWEEN 套两层）。容易漏掉的坑：
- 如果 A 表某段记录在 B 表里完全找不到重叠区间（
b.id IS NULL），说明该时间段内 B 表无对应数据——可能是新增、删除或源系统漏推 -
COALESCE(b.name, '')防止NULL导致!=判断失效；更严谨可改用NOT (a.name b.name)（MySQL）或NOT (a.name = b.name OR (a.name IS NULL AND b.name IS NULL)) - 这种写法结果行数可能爆炸——A 表一条记录若与 B 表 5 段重叠，就会返回 5 行，需后续去重或聚合
用 LAG/LEAD 窗口函数辅助识别“变化发生时刻”
单纯 JOIN 只能比两个表之间状态，但如果你要确认某条记录在 A 表内部是什么时候变的，得靠窗口函数打标记。例如查用户姓名变更的时间点：
SELECT id, name, start_date,
LAG(name) OVER (PARTITION BY id ORDER BY start_date) AS prev_name,
CASE WHEN name != LAG(name) OVER (PARTITION BY id ORDER BY start_date)
THEN start_date END AS name_changed_at
FROM dim_user_a;
这不直接参与两表 JOIN，但它是拉链表比对前的关键预处理步骤——帮你快速定位“哪些 ID 其实发生了变更”，再针对性地去 JOIN 对应时间段的 B 表记录。别忘了：PARTITION BY id 必须有，否则跨用户错位比较；ORDER BY start_date 也不能写成 end_date，因为版本顺序由生效起始时间定义。
实际做跨表拉链比对时，最容易被忽略的是时间精度——如果 start_date 是 DATETIME 类型但只存到天，而业务要求精确到秒级变更，那所有 BETWEEN 和重叠判断都会出错。
