LAG函数不能直接用于GROUP BY聚合结果，因其执行早于分组，必须先用CTE或子查询聚合，再对聚合结果开窗计算环比；需严格匹配ORDER BY与PARTITION BY字段，注意空值、索引失效及业务周期适配。
LAG 函数为什么不能直接套在 GROUP BY 结果上
直接对聚合后的结果（比如 GROUP BY month 后的 SUM(sales)）用 LAG() 会报错或返回 NULL，因为窗口函数在 SQL 执行顺序中早于 GROUP BY —— 它作用在原始行上，而非分组汇总后的“一行一月”结果。想算环比，得先聚合，再把聚合结果当新表来开窗。
正确写法：子查询或 CTE 先聚合，再用 LAG
核心思路是两层结构：外层对内层聚合结果开窗。CTE 更清晰，也避免重复写聚合逻辑。
WITH monthly_sales AS (
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(amount) AS total_sales
FROM orders
GROUP BY DATE_TRUNC('month', order_date)
)
SELECT
month,
total_sales,
ROUND(
(total_sales - LAG(total_sales) OVER (ORDER BY month)) * 100.0 / NULLIF(LAG(total_sales) OVER (ORDER BY month), 0),
2
) AS mom_pct
FROM monthly_sales
ORDER BY month;
-
NULLIF(..., 0)防止除零错误，比CASE WHEN更简洁 -
ROUND(..., 2)控制小数位，避免浮点误差干扰可读性 -
DATE_TRUNC('month', ...)是 PostgreSQL/BigQuery 写法；MySQL 用DATE_FORMAT(order_date, '%Y-%m-01')，SQL Server 用DATEFROMPARTS(YEAR(order_date), MONTH(order_date), 1)
LAG 的 ORDER BY 必须和分组键严格一致
如果 GROUP BY 按 region, month，那 LAG() 的 ORDER BY 也必须是 region, month，否则跨区域混算。更安全的做法是加 PARTITION BY region：
LAG(total_sales) OVER (PARTITION BY region ORDER BY month)
- 漏写
PARTITION BY是最常见错误，尤其多维分组时，会导致上海 3 月数据去减北京 2 月数据 -
ORDER BY中字段类型要和分组键一致，比如month是DATE类型就别用CHAR字符串排序 - 若时间字段有空值，
ORDER BY month会把它们排最前或最后（依数据库而定），建议提前WHERE order_date IS NOT NULL
性能注意：LAG 不会自动利用 GROUP BY 索引
即使 order_date 上建了索引，CTE 中的 GROUP BY DATE_TRUNC('month', order_date) 仍可能触发全表扫描——因为函数破坏了索引可用性。优化方式有限但有效：
- 在支持表达式索引的数据库（PostgreSQL、MySQL 8.0+）上，显式创建：
CREATE INDEX idx_orders_month ON orders (DATE_TRUNC('month', order_date)) - 用冗余字段替代计算：在表里加
order_month DATE列并维护（如触发器或 ETL），索引它，GROUP BY order_month就能走索引 - 大表慎用
LAG()+ 多层嵌套，可考虑先物化聚合结果到临时表，再查临时表开窗
真正麻烦的不是语法，而是确认你的 ORDER BY 和 PARTITION BY 是否真对应业务意义上的“上一期”。比如财年从 4 月开始，或者某些行业按双周滚动，这时候 LAG() 就得配合自定义序列生成，而不是无脑按自然月排。
