不能直接用 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()才能等效取出上一行值 - SQL Server 不允许在窗口帧内对同一列做「当前值 - 聚合值」的直接运算（如
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()错位 - 缺失月份未补全：2024-02 数据缺失，
LAG(sales, 1)会跳到 2024-01，导致 2024-03 的环比实际对比的是 2024-01 —— 这不是 bug，是数据问题，需在外层用递归 CTE 或日历表 LEFT JOIN 补空
别花时间调 ROWS BETWEEN 的边界，SQL Server 对窗口帧的聚合限制太死；把精力放在时间归一、排序唯一性、空值兜底这三件事上，LAG() 就能稳跑一年。
