lag()必须配合order by，否则报错或结果随机；需归一化时间周期、避免重复调用、显式处理null/零值、补全缺失时间维度以确保业务语义正确。
LAG() 必须配合 ORDER BY，否则结果不可靠
窗口函数不认表里“自然插入顺序”，只认 OVER (ORDER BY ...) 指定的逻辑顺序。漏写 ORDER BY 会直接报错；空 ORDER BY（如 OVER ()）会让 LAG() 随机取上一行，结果每次执行都可能不同。
常见错误是用原始时间字段但没处理粒度：比如 sale_date 是日级数据，但你要算月环比，直接 LAG(sales) OVER (ORDER BY sale_date) 会拿上一天值，不是上一月。必须先归一化周期，例如：
-
DATE_TRUNC('month', sale_date)（PostgreSQL） -
STR_TO_DATE(CONCAT(YEAR(sale_date), '-', MONTH(sale_date), '-01'), '%Y-%m-%d')（MySQL） -
TO_CHAR(sale_date, 'YYYY-MM')（兼容性高，但需确保字符串排序正确）
避免重复调用 LAG()，用 CTE 或子查询预提 prev_value
在同一个 SELECT 中多次写 LAG(sales) OVER (ORDER BY month)，不仅可读性差，数据库也可能重复计算——尤其当窗口复杂或数据量大时，性能下降明显。
更稳妥的做法是先用 CTE 或子查询把偏移值拎出来：
WITH monthly_with_prev AS (
SELECT
month,
sales,
LAG(sales) OVER (ORDER BY month) AS prev_sales,
LAG(sales, 12) OVER (ORDER BY month) AS prev_year_sales
FROM monthly_sales
)
SELECT
month,
sales,
prev_sales,
ROUND((sales - prev_sales) * 100.0 / NULLIF(prev_sales, 0), 2) AS mom_growth_pct
FROM monthly_with_prev;
这样既避免四次重复写 LAG()，也方便后续加 CASE 或条件过滤。
除零和 NULL 必须显式处理，不能依赖默认行为
LAG() 对首行返回 NULL，如果直接参与除法：(sales - LAG(...)) / LAG(...)，整条表达式会变成 NULL —— 这看似“安全”，但掩盖了真实问题：你无法区分“上期为 0”和“上期不存在”。而业务上，“上期为 0”往往意味着异常（比如刚起步或断货），需要告警，而非静默忽略。
推荐组合使用 NULLIF() 和 CASE：
-
NULLIF(prev_sales, 0)把 0 转成NULL，避免除零错误 -
CASE WHEN prev_sales IS NULL THEN NULL WHEN prev_sales = 0 THEN -999.99 ELSE ... END可区分空缺 vs 零值 - 乘
100.0强制浮点运算，防止整数除法截断（如5/2 = 2而非2.5）
数据不连续时 LAG() 仍按行序取值，不会自动跳过缺失周期
比如你的月度数据缺了 2025-06，那么 2025-07 的 LAG(sales) 会取 2025-05，而不是 2025-06（它不存在）。这符合函数定义，但不符合业务“环比”的语义。
解决办法只有两个：
- 补全时间维度：用
GENERATE_SERIES()（PostgreSQL）或递归 CTE 生成完整月份，再LEFT JOIN原表，让缺失月的sales为NULL，此时LAG()才真正反映“上一有效周期” - 改用时间差逻辑：如
LAG(sales) FILTER (WHERE month = ADD_MONTHS(current_month, -1))（部分数据库支持），但兼容性差，多数情况不如补维表可靠
跨年、多产品线等场景同理：只要 PARTITION BY product_id ORDER BY month 写对，LAG() 就分组内独立生效；但若某产品在某月无记录，照样会“跳过”，这点极易被忽略。
