BETWEEN会拉出多个历史版本是因为其闭区间特性及拉链表中时间重叠或end_date语义不一致，导致一行事实数据匹配多条维度记录；应改用左闭右开逻辑（t1.event_time >= t2.start_date AND t1.event_time < t2.end_date）并校验维度表时间连续性。
为什么BETWEEN会拉出多个历史版本
直接写 ON t1.id = t2.id AND t1.event_time BETWEEN t2.start_date AND t2.end_date 看似直觉正确，但实际常导致一行事实数据匹配到多条拉链记录——因为拉链表里同一 id 可能存在时间重叠的版本（ETL异常、手工补数、边界处理不一致），而 BETWEEN 是闭区间，只要 event_time 落在任一重叠段内，就全捞出来。
更隐蔽的问题是 end_date 语义混乱：有的系统用 '9999-12-31' 表示“永远有效”（闭区间），有的用 '2024-05-01' 表示“生效至前一天”（开区间）。混用时，event_time = '2024-05-01 00:00:00' 可能既命中上一版又命中新版。
- 检查维度表是否存在重叠：运行
SELECT id, COUNT(*) FROM dim_table GROUP BY id, start_date, end_date HAVING COUNT(*) > 1 - 确认
end_date实际含义：查一条已知变更记录，看新旧版本的start_date/end_date是否首尾相接（如旧版end_date = '2024-04-30'，新版start_date = '2024-05-01'） - 别依赖
BETWEEN——它无法表达“生效起始 ≤ 时间
必须用开区间语义重写JOIN条件
统一约定 end_date 为“失效时间点”，即该时刻起不再生效（开区间），这是拉链表最稳健的建模方式。JOIN 条件必须拆成两个独立不等式：
t1.event_time >= t2.start_date AND t1.event_time
这样能严格保证：任意 event_time 最多命中一个版本（前提是维度表无重叠）。即使有重叠，也能靠后续去重兜底。
- MySQL 8.0+ 中，该写法可走
idx_id_start_end (id, start_date, end_date)联合索引，避免Range checked for each record性能警告 - PostgreSQL / Spark SQL / BigQuery 支持
QUALIFY ROW_NUMBER() OVER (PARTITION BY t1.id, t1.event_time ORDER BY t2.start_date DESC) = 1直接取最新生效版本 - 如果维度表确实存在无法清理的重叠，必须加
NOT EXISTS子查询排除被更优版本覆盖的行（见知识库中 MySQL 半连接示例）
LEFT JOIN后出现NULL或重复，其实是业务逻辑没对齐
常见现象：LEFT JOIN 拉链表后，部分事实行 attr 为 NULL，或同一 t1.id 出现多行不同 attr。这不是SQL写错了，而是暴露了两个关键问题：
- 事实表
event_time落在所有拉链版本之外（早于最早start_date或晚于所有end_date），需检查维度表覆盖时间范围是否完整 - 维度表存在空缺（gap）：比如某用户在
'2024-03-15'到'2024-04-10'之间无任何版本，而事实发生在'2024-03-20'，必然 NULL - 误把拉链表当普通维度表用：拉链表天然一对多（一个ID对应多个时间版本），若业务只需要“当前最新状态”，应先用
ROW_NUMBER() OVER (PARTITION BY id ORDER BY start_date DESC)预聚合出单行视图，再 JOIN
最容易被忽略的点：拉链表的主键从来不是id
拉链表真正的自然主键是 (id, start_date) 或 (id, version)，而不是单独的 id。一旦在 JOIN 后做 GROUP BY t1.id 或 DISTINCT t1.id，就等于主动放弃时间维度，把不同快照混为一谈——这比重复更危险，因为它悄悄扭曲了业务语义。
真正要防的不是“重复行”，而是“用错快照”。比如查“用户下单时的地址”，必须绑定下单时刻；查“当前用户地址”，就得过滤出 end_date = '9999-12-31'（或最大 start_date）的那条。这两者不能共用一个 JOIN 写法。
