使用LAG()计算分组内相邻行差值时，必须显式指定ORDER BY和PARTITION BY，否则会导致跨组串数据或结果不可预测；实操中应采用LAG(value,1)OVER(PARTITIONBYregionORDERBYdt)并统一时间粒度、防除零与NULL、确保多维分组键完整、警惕数据倾斜。
用 LAG() 计算分组内相邻行差值时，必须显式指定 ORDER BY 和 PARTITION BY
不加 PARTITION BY 会导致跨组“串数据”，比如把北京上月销量和上海本月强行拉一起算差；不写 ORDER BY 则结果不可预测——数据库不保证物理顺序，LAG() 可能取到任意一行的值。
实操建议：
-
LAG(value, 1) OVER (PARTITION BY region ORDER BY dt)是安全基线，dt必须是明确可排序的时间字段（如DATE类型，避免用字符串'202401'） - 若时间字段含时分秒但只需按日环比，先用
CAST(dt AS DATE)或DATE_TRUNC('day', dt)（PostgreSQL）统一粒度 - MySQL 8.0+ 支持
LAG()，但 5.7 不支持，此时得用自连接或变量模拟，性能差且易出错
计算环比增长率要防除零和 NULL，别直接写 (cur - prev) / prev
当上期值为 0 或 NULL 时，表达式会返回 NULL 或报错（如 PostgreSQL 的 division by zero），前端常显示为空白，但没人知道是真没数据还是计算崩了。
实操建议：
- 用
NULLIF(prev, 0)把除数为 0 转成NULL，再配合COALESCE((cur - prev) / NULLIF(prev, 0), 0)填 0（或按业务填NULL） - 如果上期值是
NULL（比如首条记录），LAG()返回NULL，此时cur - NULL仍是NULL，需用CASE WHEN prev IS NULL THEN NULL ELSE ... END显式控制 - 增长率建议乘 100 并保留小数：
ROUND(COALESCE((cur - prev) / NULLIF(prev, 0), 0) * 100, 2)
多维度分组（如 region + product）时，PARTITION BY 要覆盖所有业务分组键
只写 PARTITION BY region 会导致同一地区不同产品的数据混排，比如手机和平板的销量被当成同一条时间线算环比，结果完全失真。
实操建议：
- 分组维度必须和业务分析口径严格一致：若看“各城市各品类月度表现”，
PARTITION BY city, category ORDER BY ym（ym是年月整数或字符串） - 注意字段类型一致性：
city若有大小写混用（如'Beijing'和'beijing'），需统一用UPPER(city)再分组，否则视为不同组 - 分区键过多会降低窗口函数性能，但比逻辑错误代价小；必要时建组合索引加速
(city, category, ym)
在 Hive/Spark SQL 中用 LAG() 需警惕数据倾斜和内存溢出
Hive 默认对每个 PARTITION BY 组做全量 shuffle，若某城市占 90% 数据（如“全国总览”伪城市），该 reducer 会 OOM，任务卡死。
实操建议：
- 提前过滤掉异常大组，或用
DISTRIBUTE BY RAND()打散后再SORT BY，但会牺牲局部有序性，慎用于时间序列 - Spark 中可设
spark.sql.adaptive.enabled=true启用自适应查询优化，自动切分大 partition - 更稳的做法是先用
GROUP BY + COLLECT_LIST(STRUCT(dt, value))汇总每组数据，再用 UDF 在 driver 端逐组计算差值——适合组数不多、单组数据量可控的场景
实际跑通的关键往往不在公式多炫酷，而在确认每组数据边界是否干净、时间字段是否真有序、零值是否被显式兜底。漏掉其中一环，结果看着像对，其实已经偏了。
