窗口函数嵌套致性能断崖，需拆解为 CTE/ 临时表；NULL 须在窗口内用 COALESCE 预处理；滚动计算优先用 RANGE 而非 ROWS，并补全日历；索引需覆盖 WHERE 与 ORDER BY 字段。
窗口函数嵌套导致性能断崖式下降
财务报表里常见“同比环比 + 滚动均值 + 分组累计”三重叠加，直接嵌套 LAG()、AVG() OVER ()、SUM() OVER () 会触发多次全表扫描。PostgreSQL 和 MySQL 8.0+ 虽支持多层窗口，但优化器往往无法复用中间结果。
实操建议：
- 把复合逻辑拆成 CTE 或临时表：先算好基础指标（如月度收入），再在上层做同比 / 滚动计算，避免同一行数据被反复送入不同窗口框架
- 确认分区键是否真正覆盖查询过滤条件——比如按
account_id分区却只查report_date BETWEEN ……，会导致大量无效分区扫描 - MySQL 中慎用
ORDER BY+ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW计算累计值，若ORDER BY字段有重复值且无唯一辅助排序（如加id），结果可能非确定
财务口径下 NULL 处理引发指标错位
财务系统常要求“空值视为 0 参与计算”，但 SUM() OVER () 默认跳过 NULL，而 COALESCE(x, 0) 放在窗口内或外位置不同，结果天差地别。
实操建议：
- 必须在窗口函数输入前补 NULL：写成
SUM(COALESCE(revenue, 0)) OVER (PARTITION BY period ORDER BY date)，而不是COALESCE(SUM(revenue) OVER (……), 0)——后者是汇总后补零，漏掉了 NULL 对累计逻辑的影响 - 同比计算中，若基期为 NULL，
LAG(revenue) OVER (……) IS NULL不代表没数据，可能是当期为 0 但基期缺失；建议统一用LAG(COALESCE(revenue, 0))并配合CASE WHEN LAG(……) IS NULL THEN 0 ELSE …… END显式控制 - Oracle 用户注意
NVL()和COALESCE()在窗口中的行为一致，但前者不支持表达式短路，有潜在性能差异
跨会计期间滚动计算的边界陷阱
财务滚动 12 个月（YTD）、滚动 3 期（QTD）等需求，容易忽略会计期间非自然月（如财年从 4 月开始）、月末关账延迟导致数据滞后等问题。
实操建议：
- 别依赖
CURRENT_DATE算滚动窗口，改用报表参数传入@report_period（如 ‘2024-03-31’），再用日期函数推导起始点：DATE_SUB(@report_period, INTERVAL 11 MONTH)（MySQL）或@report_period - INTERVAL '11' MONTH（PostgreSQL） -
ROWS BETWEEN 11 PRECEDING AND CURRENT ROW是按行数滚动，不是按月；若某月无交易记录，该月就直接被跳过，滚动窗口实际不足 12 个自然月——必须用RANGE BETWEEN INTERVAL '11' MONTH PRECEDING AND CURRENT ROW（仅 PostgreSQL / Oracle 支持），或提前补全日历维度表 - SQL Server 不支持
RANGE的时间间隔，只能用自连接或LEAD/LAG手动展开，复杂度陡增，建议在 ETL 层完成补期
窗口函数与索引失效的隐性冲突
即使给 report_date 建了索引，只要窗口定义含 ORDER BY report_date 且查询带 WHERE account_type = 'REVENUE'，优化器仍可能放弃索引走全表扫描——因为窗口需要全局有序，而索引只对满足 WHERE 的子集有效。
实操建议：
- 优先建组合索引：
INDEX (account_type, report_date)，让 WHERE + ORDER BY 同时命中 - 避免在窗口
ORDER BY中使用函数，如ORDER BY YEAR(report_date)会让索引失效；改用生成列或预计算字段 - 对大宽表（>50 列），窗口计算前加
SELECT /*+ INDEX(t idx_acct_date) */ ……（Oracle）或/*+ USE_INDEX(t idx_acct_date) */（MySQL）强制走索引，但需验证执行计划是否真用了
财务指标的“正确性”往往卡在细节：一个未声明的 NULL 处理顺序、一行索引缺失、一次错误的 ROWS vs RANGE 选择，就可能让千万级报表跑出偏差百分比。这些地方没法靠“加资源”解决，只能逐层压住计算路径。
