LAG函数自SQL Server 2012（11.x）起原生支持，此前版本不识别该函数；即使实例为2012+，若数据库兼容级别低于110（如设为100），仍会报错；SQL Server 2022及Azure SQL新增IGNORE NULLS选项，但CU4前存在Bug；必须配合ORDER BY使用，分组需显式指定PARTITION BY，否则逻辑错误。

SQL Server 2012 是 LAG 函数的起始支持版本

LAG 函数从 SQL Server 2012 (11.x) 开始原生支持，此前版本（如 2008 R2 或更早）无法直接使用该函数。如果你在低版本 SQL Server 上执行 LAG()，会收到类似 ‘LAG’ is not a recognized built-in function name. 的错误。

检查当前数据库兼容性级别是否达标

即使 SQL Server 实例是 2012 或更高版本，如果数据库的兼容性级别被手动设为低于 110（例如 100 对应 SQL Server 2008），LAG() 仍不可用。

• 运行 SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME(); 查看当前值
• 低于 110 就必须升级：执行 ALTER DATABASE [your_db] SET COMPATIBILITY_LEVEL = 110;
• 注意：ALTER DATABASE 会清空计划缓存，可能短暂影响查询性能

LAG 在 Azure SQL 和较新版本中的扩展行为

SQL Server 2022（16.x）及 Azure SQL 数据库支持 IGNORE NULLS 选项，但该功能在 SQL Server 2022 CU4 之前存在 Bug；若需稳定使用此特性，建议确认补丁版本或改用 ROW_NUMBER() + 子查询模拟。

• LAG(col, 1, 0) OVER (ORDER BY ts) —— 第三个参数 0 是默认值，仅在偏移超出范围时生效
• LAG(col) OVER (PARTITION BY user_id ORDER BY ts) —— 缺少 PARTITION BY 会导致跨用户混算，这是最常被忽略的逻辑错误
• 排序字段 ts 必须具有确定性；若时间戳重复，建议追加唯一列如 id 防止结果不稳定

替代方案：没有 LAG 时怎么模拟前一行取值

在不支持 LAG() 的旧环境（如 SQL Server 2008），只能靠自联接或相关子查询，但性能和可读性都差很多。

• 典型写法：LEFT JOIN t AS prev ON curr.date = DATEADD(day, 1, prev.date) —— 前提是日期连续，节假日场景会断裂
• 更健壮的子查询：(SELECT TOP 1 ClosePrice FROM MicrosiftStockHistory m2 WHERE m2.StockDate
• 这类写法在大表上极易产生嵌套循环，务必确保 StockDate 有索引

真正麻烦的不是语法写不对，而是误以为 LAG() 能自动处理业务语义——比如“上一个交易日”不等于“物理上一行”，它只认 ORDER BY 定义的顺序，而这个顺序是否贴合业务，得你来保证。