LAG函数必须配合PARTITION BY分组字段和ORDER BY时间升序字段使用，否则无法正确获取上期分组数据；需用CASE WHEN处理NULL和除零异常，并建议ROUND控制小数位。
LAG函数怎么写才能正确取到上期分组数据
直接用 LAG(value) 不加分区或排序，结果一定是错的——它会按整个结果集顺序取值，完全忽略业务上的“每组独立计算”。必须显式指定 PARTITION BY 和 ORDER BY，否则环比毫无意义。
-
PARTITION BY要填业务分组字段，比如PARTITION BY product_id或PARTITION BY region，确保每个产品/区域各自拉取自己的上期值 -
ORDER BY必须是时间维度（如ORDER BY year_month或ORDER BY stat_date），且顺序要升序；降序会导致取到下期而非上期 - 如果时间字段有重复（如多条同月记录），需额外加唯一排序字段，例如
ORDER BY year_month, id，避免窗口函数非确定性取值
计算环比时NULL值和除零怎么处理
LAG取不到上期数据时返回NULL，直接参与除法会拖垮整列结果；上期值为0时又会触发除零错误。这两类问题必须在计算前拦截。
- 用
COALESCE(LAG(value), 0)只能掩盖问题，正确做法是保留NULL并用CASE WHEN分离逻辑：上期为空时，环比设为NULL或标记为'new' - 除零必须显式判断：不要写
(cur - prev) / prev，而要写CASE WHEN prev = 0 THEN NULL ELSE (cur - prev) / prev END - 建议统一用
ROUND(..., 4)控制小数位，避免浮点误差干扰业务判断
不同数据库对LAG的兼容性差异
MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持标准 LAG()，但 SQLite 和旧版 MySQL（
- MySQL 5.7 或更早：只能用自连接或变量模拟，性能差且易出错，建议先升级或改用应用层计算
- PostgreSQL 支持
LAG(value, offset, default)的第三个参数（默认值），可简化NULL处理，如LAG(sales, 1, 0) - SQL Server 中
LAG对ORDER BY字段要求更严，若排序字段含NULL，需明确写ORDER BY col ASC NULLS LAST（2022+）或提前过滤
为什么算出来环比全是0或者明显偏离预期
大概率是时间粒度没对齐。比如原始数据是日粒度，但你按月分组后直接对月汇总值用LAG，却忘了在窗口函数里也按月排序——结果可能拿7月31日去比7月1日，而不是比6月30日。
- 确保
PARTITION BY和外层GROUP BY的分组维度一致（都按月？都按周？） - LAG里的
ORDER BY字段必须是聚合后的时间标识，例如先用DATE_TRUNC('month', order_time)或CONCAT(YEAR(d), '-', LPAD(MONTH(d),2,'0'))生成标准月份字段，再用于排序 - 检查是否有数据跨时区或时间字段类型是字符串——字符串排序 “2023-10” 会排在 “2023-2” 后面，导致逻辑错乱
实际中最容易被跳过的，是时间字段标准化这一步。很多人直接拿原始日期列进 ORDER BY，看着语句跑通了，结果环比数字全错，排查半天才发现是字符串排序惹的祸。
