财务报表中LAG()遇NULL致增幅为NULL，应使用NULLIF避免除零；PARTITION BY须在ORDER BY前；季度排序需转可比日期；PERCENT_RANK()与CUME_DIST()适用场景不同；禁用窗口嵌套聚合。
LAG() 计算上期值时 NULL 导致增幅为 NULL
财务报表里算环比增长，最常踩的坑是 LAG() 返回 NULL，导致 (current - lag) / lag 整个表达式变成 NULL，而不是你想要的“无上期数据不计算”或“显示 0%”。这在首行、跨年切换、缺失月份等场景特别明显。
实操建议：
- 用
COALESCE(LAG(value) OVER (ORDER BY date), 0)强制补 0 —— 但注意：除零错误会报错，得再套一层NULLIF - 更稳妥写法：
(value - LAG(value) OVER (ORDER BY date)) / NULLIF(LAG(value) OVER (ORDER BY date), 0) - 如果只想保留有同比意义的行（即排除首行），直接加
WHERE LAG(value) OVER (ORDER BY date) IS NOT NULL
按财年/季度分组后做窗口计算，ORDER BY 和 PARTITION BY 搞反顺序
比如要算每个季度内各产品线的月度环比，结果发现增幅全乱了——大概率是 PARTITION BY quarter 写对了，但 ORDER BY month 没跟上，或者把 ORDER BY 放在了 PARTITION BY 前面导致逻辑分区失效。
实操建议：
-
PARTITION BY必须先于ORDER BY，顺序不能换；否则窗口只在全局排序，不分组 - 财务日期字段常是字符串（如
'2024-Q1'），直接ORDER BY会按字典序排成 Q1、Q10、Q2；应转成可比较格式，例如：TO_DATE(quarter || '-01', 'YYYY-QQ-DD')或用CASE WHEN映射顺序 - 季度内月份可能跨自然年（如 FY2024 从 2023-07 开始），别依赖
EXTRACT(MONTH FROM ...)直接排序
PERCENT_RANK() 和 CUME_DIST() 在排名类指标中选错函数
做营收贡献度排名、客户分级时，有人用 PERCENT_RANK() 算“前 20% 客户”，结果发现边界不准——因为 PERCENT_RANK() 把最小值固定为 0，最大值固定为 1，中间按 (rank-1)/(n-1) 算，而 CUME_DIST() 是按 ≤ 当前值的行数占比，更贴近业务常说的“累计占比”。
实操建议：
- 要“有多少客户贡献了不到 X% 营收”，用
CUME_DIST() OVER (ORDER BY revenue DESC) - 要“当前客户在所有客户中的相对位置（含并列）”，用
PERCENT_RANK()；但注意它对并列值返回相同结果，且首尾强制为 0 和 1 - 两者都不处理
NULL，若营收字段有空值，先用WHERE revenue IS NOT NULL过滤，否则排名结果不可控
窗口函数嵌套聚合导致执行计划变慢
写成 AVG(LAG(sales) OVER (...)) OVER (...) 这种嵌套，PostgreSQL 会尝试物化中间结果，MySQL 8.0 可能直接报错；尤其在千万级财务明细表上，响应时间从毫秒跳到秒级。
实操建议：
- 避免在窗口函数内部再套窗口函数；把
LAG()提前算成一列，再在外面聚合 - 用 CTE 拆解步骤：
WITH t1 AS (SELECT *, LAG(sales) OVER (...) AS prev_sales FROM ...) SELECT ..., (sales - prev_sales) / NULLIF(prev_sales, 0) FROM t1 - 确保
ORDER BY字段有索引；财务场景常用(account_id, report_date)复合索引，而非单列report_date
财务数据对空值、边界、时序连续性极度敏感，窗口函数不会自动帮你补数、对齐周期或跳过异常点。每一步 OVER 子句都要想清楚：这个 PARTITION 是否覆盖了所有业务维度？ORDER BY 的值是否真正可比？NULL 是该被忽略、替换，还是本身就是关键信号？
