视图不能写where valid_from @as_of_time，因其不支持运行时参数，@as_of_time非法；硬编码时间则丧失回溯能力，必须由外部查询注入条件实现版本过滤。
视图本身不能“切换”版本，它只是返回带时间戳的宽表；真正实现“查某时刻版本”的动作，必须由外部 SQL 注入 WHERE 条件完成。
为什么视图里不能写 WHERE valid_from @as_of_time
SQL 视图不支持参数，@as_of_time 在视图定义中是非法变量，直接写会报错或被当成字面量处理。更危险的是硬编码具体时间（如 WHERE valid_from ），会导致所有调用该视图的查询都被强制锁定到那个时间点，彻底失去回溯能力。
- 视图一旦定义，就固定输出结果集结构，无法动态响应不同时间点请求
- 用户想查 2023-06-15 的状态，但视图只返回 2024-01-01 有效的记录，数据就丢了
- 即使数据库支持内联表值函数（如 PostgreSQL 的
get_version_at()），那也不是“视图”，而是函数封装
视图该返回什么字段才支持灵活回溯
核心是提供可做区间判断的边界字段，且语义清晰、NULL 可控。推荐使用左闭右开区间：valid_from（含） + valid_to（不含），并显式处理“至今有效”场景。
-
valid_from：非 NULL，表示该版本生效起始时间点 -
valid_to：允许为 NULL，代表“当前仍有效”；在外部查询中需写成valid_to IS NULL OR valid_to > @as_of_time - 避免用
effective_date单字段——它只能表达“从这天开始生效”，无法界定结束，无法支持快照查询 - 若源是事务日志，必须用窗口函数生成连续区间，例如：
LEAD(valid_from) OVER (PARTITION BY id ORDER BY valid_from) AS valid_to
对接时间维度表时怎么避免重复或漏数据
直接 JOIN dim_date ON d.date_key = v.valid_from 是典型错误：维度表按日粒度，而业务时间可能是秒级；等值连接只会匹配起始当天，完全忽略跨日期的有效期。
- 正确方式是范围 JOIN：
ON d.date_key >= DATE(v.valid_from) AND (d.date_key - 注意类型对齐：若
dim_date.date_key是DATE类型，而v.valid_from是DATETIME2，必须用DATE(v.valid_from)截断，否则永远不等 - NULL 的
valid_to必须显式兜底，否则那些“至今有效”的版本会被整个过滤掉 - 这种 JOIN 在大宽表上容易引发笛卡尔积，务必在
v.id和d.date_key上建好组合索引
性能差是不是因为视图里用了 LEAD() 窗口函数
是。窗口函数在视图定义中每次调用都会重算，尤其当底层数据量大、分区多时，LEAD() OVER (PARTITION BY id ORDER BY valid_from) 会触发全排序，执行计划常退化为 Table Spool + Sort，IO 和 CPU 开销陡增。
- 如果源表已维护好拉链结构（即每条记录自带
valid_from/valid_to），就别在视图里再算一遍 - 如果必须从日志生成拉链，建议把窗口逻辑下沉到物化中间表，视图只做轻量 SELECT
- SQL Server 中可考虑用
SCHEMABINDING+ 索引视图固化计算结果，但要求所有引用表都带架构名且不能有 NULL 列 - MySQL 用户请放弃参数化幻想——它没有内联表值函数，也不支持索引视图，老实用宽表 + 外层
WHERE
最容易被忽略的一点：valid_to 的 NULL 含义和区间判断逻辑必须前后统一。有人用闭区间（），有人用左闭右开（<code>），混用会导致某天的数据莫名消失或重复出现。定下来就别改，文档里写清楚，所有下游查询照着抄。
