temporal table的join必须指定有效时间范围，直接对系统版本表（for system_time all）做join会返回大量重复或无效记录，因为历史行的时间区间可能重叠或不匹配。
Temporal Table的JOIN必须指定有效时间范围
直接对系统版本表（FOR SYSTEM_TIME ALL）做JOIN会返回大量重复或无效记录，因为历史行的时间区间可能重叠或不匹配。关键不是“能不能JOIN”，而是“在哪个时间点对齐”。SQL Server不会自动按时间对齐两表的历史状态，你得显式控制时间切片。
常见错误是写成：SELECT * FROM Orders FOR SYSTEM_TIME ALL o JOIN Customers FOR SYSTEM_TIME ALL c ON o.CustomerID = c.CustomerID——这会产生笛卡尔积级的膨胀结果，每条订单历史行都和所有客户历史行配对，毫无业务意义。
- 正确做法：用
FOR SYSTEM_TIME AS OF <timestamp></timestamp>在统一时间点快照两表 - 或者用
FOR SYSTEM_TIME BETWEEN ... AND ...限定共同有效时段 - 若需跨时段关联（如“下单时客户的地址”），必须用子查询或APPLY按
Orders.ValidFrom去查Customers在该时刻的状态
用AS OF实现“某时刻的完整业务快照”
这是最常用也最安全的场景：你想知道2024-03-15 10:00:00时，订单和对应客户的完整状态。此时两表都用AS OF，SQL Server会各自取该时间点的有效行，再基于主键JOIN。
SELECT o.OrderID, o.Amount, c.CustomerName, c.Address FROM Orders FOR SYSTEM_TIME AS OF '2024-03-15T10:00:00' o JOIN Customers FOR SYSTEM_TIME AS OF '2024-03-15T10:00:00' c ON o.CustomerID = c.CustomerID;
注意：AS OF时间必须是datetime2精度，且不能超出表中ValidFrom/ValidTo覆盖范围；如果某行在该时刻尚未生效或已过期，就不会出现在结果里。
用CROSS APPLY获取“事件发生时关联实体的状态”
当需要动态对齐不同生命周期的实体（比如订单创建时客户是什么地址），AS OF静态快照不够用，必须逐行计算。这时CROSS APPLY比JOIN更自然，因为它允许把时间点作为参数传入子查询。
典型错误是试图在JOIN条件里写o.ValidFrom = c.ValidFrom——这完全忽略了历史行的时间区间关系，大概率匹配失败。
- 正确逻辑：对每条订单，查
Customers在o.ValidFrom时刻有效的那条记录 - 子查询中必须用
FOR SYSTEM_TIME AS OF o.ValidFrom，且WHERE过滤要包含时间有效性（c.ValidFrom o.ValidFrom） - 为避免NULL，建议加
OUTER APPLY并处理客户不存在的情况
SELECT o.OrderID, o.ValidFrom AS OrderTime, ca.CustomerName, ca.Address FROM Orders o OUTER APPLY ( SELECT TOP 1 CustomerName, Address FROM Customers FOR SYSTEM_TIME AS OF o.ValidFrom WHERE CustomerID = o.CustomerID ORDER BY ValidFrom DESC ) ca;
性能陷阱：历史表JOIN容易触发全表扫描
Temporal Table的系统版本表默认只有聚集索引在ValidFrom, ValidTo上，但JOIN时如果没把时间条件推到子查询里，SQL Server优化器可能放弃使用该索引，转而扫描整个历史表。
例如：用JOIN Customers FOR SYSTEM_TIME ALL再在WHERE里加时间过滤，等价于先拼全量历史再过滤，极慢。
- 务必让时间谓词落在
FOR SYSTEM_TIME子句内部，而非外部WHERE - 对高频查询的字段（如
CustomerID），考虑在系统版本表上手动添加非聚集索引：CREATE INDEX IX_Customers_History_CustomerID ON [CustomersHistory](CustomerID) INCLUDE (ValidFrom, ValidTo, CustomerName) - 注意：系统版本表名是自动生成的（如
dbo.MSSQL_TemporalHistoryFor_123456789），建索引前需用sys.tables查真实名称
时间对齐逻辑越复杂，越容易漏掉索引或写错时间边界；一旦发现执行计划里出现“Clustered Index Scan”扫几百万行，八成是时间条件没下推到位。
