先来看一个SQL Server环比计算中常见的误区：许多开发者第一时间想到的是使用 ROWS BETWEEN 1 PRECEDING AND CURRENT ROW。结果算出来一组数字，看似合理，实则完全错误——因为这个窗口帧取的是两行，而不是单独一行。简而言之，如果你执行 SUM(sales) OVER (ORDER BY order_date ROWS BETWEEN 1 PRECEDING AND CURRENT ROW)，得到的是“本月+上月”的累计和，并非纯粹的上一月数值。环比需要的是单月的数据用于差值或除法，一旦用错，后续整个计算链都会崩溃。更麻烦的是，这种错误表面上看不出来，排查起来极其耗时。
强烈不建议直接使用 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)—— 明确获取上一行的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() 就能稳健运行一整年。
