必须显式使用PARTITION BY分组字段和ORDER BY时间升序字段，如LAG(sales) OVER (PARTITION BY product_id ORDER BY order_month)，否则会跨组混取数据；NULL值和除零需用NULLIF(prev, 0)和CASE WHEN联合防护。
LAG函数怎么写才能正确取到上期分组数据
LAG() 默认不按分组处理，直接套用会跨组混用数据。必须配合 PARTITION BY 明确划分逻辑边界，否则上期值可能来自其他业务线或区域。
- 分组字段要和最终
GROUP BY保持一致，比如按product_id和month分组，PARTITION BY就得写product_id - 排序字段决定“上期”定义，通常用时间字段（如
order_month），且必须用ORDER BY升序，否则LAG(value, 1)拿到的是下期 - 如果时间有空缺（比如某月无销售），
LAG仍按行序取前一行，不会自动跳过——这不是缺陷，而是设计行为，需额外处理空档
SELECT
product_id,
order_month,
sales_amt,
LAG(sales_amt, 1) OVER (
PARTITION BY product_id
ORDER BY order_month
) AS prev_sales
FROM sales;
计算环比增长率时NULL值怎么安全处理
LAG() 对每组首行返回 NULL，直接做除法会导致整行结果为 NULL。不能只靠 COALESCE(prev_sales, 0)，因为除零错误（sales_amt / 0）会报错或返回异常值。
- 用
CASE WHEN prev_sales IS NULL THEN NULL ELSE ... END显式跳过首期 - 若需显示“—”或“新上线”，改用字符串拼接，但注意类型统一：
CAST或TO_CHAR配合 - 别在外部
WHERE prev_sales IS NOT NULL过滤——这会丢掉首期记录，而环比分析常需标记“首期无环比”
SELECT
product_id,
order_month,
ROUND(
(sales_amt - prev_sales) * 100.0 / NULLIF(prev_sales, 0),
2
) AS mom_pct
FROM (
SELECT
product_id,
order_month,
sales_amt,
LAG(sales_amt) OVER (
PARTITION BY product_id
ORDER BY order_month
) AS prev_sales
FROM sales
) t;
为什么结果里出现小数精度异常或负无穷
常见于 sales_amt 是整型、prev_sales 为 0 或 NULL 的组合场景，本质是隐式类型转换和除零未拦截。
-
100 / 0在多数数据库中抛异常（PostgreSQL）、返回Infinity（某些版本的Redshift）、或静默转为NULL（MySQL 8.0+ 严格模式外），行为不统一 - 整型相除会截断小数，例如
150 / 200 = 0，再乘 100 还是 0，必须提前转浮点：100.0 * (sales_amt - prev_sales) / NULLIF(prev_sales, 0) -
NULLIF(prev_sales, 0)是关键：它把 0 转成NULL，使整个除法结果为NULL，避免崩溃，比CASE WHEN prev_sales = 0 THEN NULL ELSE ... END更简洁
跨月但非标准日历（如财年4月起始）怎么对齐
LAG() 只认排序顺序，不管语义。如果“上期”指财务上期（如当前是 FY2025-M03，则上期是 FY2025-M02），但原始数据用自然月 '2025-03' 存储，那就得先标准化时间维度。
- 不要依赖字符串比较（
'2025-02' < '2025-03'可行但脆弱），优先转为可排序的财年月序号：(year - CASE WHEN month < 4 THEN 1 ELSE 0 END) * 100 + ((month - 4 + 12) % 12 + 1) - 或预计算一列
fiscal_period，再在ORDER BY中使用它 - 时间格式不一致（如
'202503'vs'2025-03'）会导致排序错乱，LAG取错行，务必统一清洗
实际业务中，环比计算最易被忽略的是分组键与时间粒度的耦合关系——比如按 region + product 分组，但时间字段只到年份，那 LAG 就失去意义；或者补了缺失月份却没补对应销售额（0），导致 LAG 跳过真实空档。这些不在SQL语法层，但在结果可信度上起决定作用。
