sql server中lag/lead必须完整书写over子句（含partition by和order by），否则报错或逻辑错误；需用coalesce/case处理null和除零；连续趋势分析须用cte先计算再过滤；时间断层需依赖日历表补全。
LAG/LEAD 在 SQL Server 中必须带完整 OVER 子句
SQL Server 严格要求 LAG 和 LEAD 必须写全 OVER，漏掉 ORDER BY 直接报错：Window function 'LAG' requires an ORDER BY clause；漏 PARTITION BY 则导致跨组取值——比如用户 A 的首笔订单，LAG 可能取到用户 B 的末笔金额。
常见错误写法：
-
LAG(amount) OVER (PARTITION BY user_id)—— 缺ORDER BY，报错 -
LAG(amount) OVER (ORDER BY sale_date)—— 缺PARTITION BY，全表混算
正确写法必须同时包含分组和排序：
LAG(amount) OVER (PARTITION BY user_id ORDER BY sale_date, id)
注意：时间字段重复时（如多笔同日订单），务必补上唯一列（如 id 或 create_time）防止排序不确定。
分组内计算环比增长要防 NULL 和除零
SQL Server 不支持 LAG 的第三参数（默认值），所以 LAG(sales, 1, 0) 会语法报错。必须用 COALESCE 或 CASE WHEN 处理边界值。
典型错误是直接做除法：(sales - LAG(sales)) / LAG(sales)，首行 LAG 返回 NULL，整列变 NULL；若上期为 0，还会触发除零错误。
安全写法示例：
SELECT
user_id,
sale_date,
sales,
COALESCE(LAG(sales) OVER (PARTITION BY user_id ORDER BY sale_date), 0) AS prev_sales,
CASE
WHEN LAG(sales) OVER (PARTITION BY user_id ORDER BY sale_date) = 0 THEN NULL
ELSE ROUND((sales - LAG(sales) OVER (PARTITION BY user_id ORDER BY sale_date)) * 100.0 / LAG(sales) OVER (PARTITION BY user_id ORDER BY sale_date), 2)
END AS mom_pct
FROM sales_data
关键点：
- 所有
LAG(sales)的OVER子句必须完全一致，避免优化器重排导致值错位 - 别用
ISNULL(LAG(...), 0)做除数——0 仍会导致除零，要用CASE显式拦截 - 如果业务允许“首期视为无变化”，可用
COALESCE(LAG(sales), sales)
识别连续趋势需用子查询或 CTE 包一层
想查“连续 3 期上涨”的用户，不能在 WHERE 里直接写 COUNT(*) OVER (...)，SQL Server 报错：Windowed functions can only appear in the SELECT or ORDER BY clauses。
必须把窗口计算结果先产出，再在外层过滤：
WITH trend AS (
SELECT
user_id,
sale_date,
sales,
sales - COALESCE(LAG(sales) OVER (PARTITION BY user_id ORDER BY sale_date), 0) AS diff,
COUNT(*) OVER (
PARTITION BY user_id
ORDER BY sale_date
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
) AS window_size
FROM sales_data
)
SELECT user_id
FROM trend
WHERE diff > 0 AND window_size = 3
注意：
-
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW定义滑动窗口大小为 3 行 - 若用
RANGE而非ROWS，时间重复时可能拉入更多行，结果失真 - 大分组（如百万级用户）下，
OVER窗口性能敏感，确保(user_id, sale_date)有复合索引
时间断层问题在 SQL Server 中必须手动补全
SQL Server 没有 GENERATE_SERIES，也不支持递归 CTE 的无限深度（默认 100 层），补全缺失月份得靠日历表或临时数字表。
简单可靠的做法是建一个最小粒度的日期辅助表（如 calendar），再与用户维度 CROSS JOIN 后 LEFT JOIN 原表：
SELECT u.user_id, c.sale_month, COALESCE(s.sales, 0) AS sales FROM (SELECT DISTINCT user_id FROM sales_data) u CROSS JOIN (SELECT DISTINCT DATEFROMPARTS(YEAR(sale_date), MONTH(sale_date), 1) AS sale_month FROM sales_data) c LEFT JOIN sales_data s ON u.user_id = s.user_id AND c.sale_month = DATEFROMPARTS(YEAR(s.sale_date), MONTH(s.sale_date), 1)
容易踩的坑：
- 用
INNER JOIN替代LEFT JOIN，会把空月份过滤掉 - 没对
sale_month去重，CROSS JOIN产生笛卡尔爆炸 - 补完后没用
COALESCE(s.sales, 0)，后续LAG仍遇到NULL
真实业务中，时间断层比函数写法更常成为趋势分析失准的根源——函数逻辑再严谨，输入数据缺了一月，环比就跳档。
