不能直接用 ROWS BETWEEN 1 PRECEDING AND CURRENT ROW 做环比,因其取当前行与上一行共两行,导致计算结果为“本月+上月”和而非纯上月值;正确做法是使用 LAG(sales, 1) OVER (ORDER BY order_date),并确保排序唯一、时间粒度归一、缺失月份补全。
不能直接用 ROWS BETWEEN 1 PRECEDING AND CURRENT ROW 做环比——它取的是两行,不是上一行;真要硬用窗口帧,必须写成 ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING,但强烈建议改用 LAG()。
ROWS BETWEEN 1 PRECEDING AND CURRENT ROW 算不出环比这个范围包含当前行 + 上一行共两行。如果你对销售额做 SUM(sales) OVER (...),结果是「本月 + 上月」的和,不是上月单值。环比需要的是纯上月值,用来做减法或除法。误用会导致整个计算链错乱,且难以排查——表面看有值,实际语义全错。
ROWS BETWEEN 1 PRECEDING AND CURRENT ROW → 2 行窗口 → 适合移动平均,不适合取上一行ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING → 1 行窗口 → 配合 MAX() 或 MIN() 才能等效取出上一行值sales - SUM(sales) OVER (...)),会报错 Windowed functions cannot be used in the context of another windowed function
LAG() 是 SQL Server 中唯一可靠、可读、可维护的环比方案SQL Server 2012+ 完全支持 LAG(),语法清晰,行为确定,且自动处理边界和空值逻辑。
LAG(sales, 1) OVER (ORDER BY order_date) —— 明确取上 1 行的 sales
LAG(sales, 1, 0) OVER (ORDER BY order_date) —— 首行返回 0 而非 NULL,避免后续计算崩掉NULLIF(LAG(sales, 1), 0) 必须套在分母位置,否则 / 0 直接报错ORDER BY order_date, sales_id —— 否则相同日期下 LAG() 返回哪一行不可控不是函数不会写,而是数据和上下文没对齐。
ORDER BY 字段无索引:SQL Server 会强制排序,大数据量下性能骤降;确保 order_date 或组合字段有索引DATEFROMPARTS(YEAR(dt), MONTH(dt), 1) 归一化,否则同月多行导致 LAG() 错位LAG(sales, 1) 会跳到 2024-01,导致 2024-03 的环比实际对比的是 2024-01 —— 这不是 bug,是数据问题,需在外层用递归 CTE 或日历表 LEFT JOIN 补空别花时间调 ROWS BETWEEN 的边界,SQL Server 对窗口帧的聚合限制太死;把精力放在时间归一、排序唯一性、空值兜底这三件事上,LAG() 就能稳跑一年。