用窗口函数替代多层JOIN做累计统计结果对不上，根本原因是JOIN会因重复维度组合导致行数爆炸、SUM失真，而窗口函数在原始行上计算、天然保真。
用窗口函数替代多层JOIN做累计统计时，为什么结果总对不上？
根本原因是 JOIN 改变行数而窗口函数不改变——一旦原表有重复维度组合（比如同一用户多笔订单），JOIN 会爆炸式膨胀数据，再 SUM() 就失真；窗口函数则在原始行上计算，天然保真。
- 先确认业务逻辑是否真需要“每行带当前累计值”：是 → 用
SUM() OVER (ORDER BY ...)；否 → 可能只需GROUP BY聚合 - 注意
ORDER BY子句必须明确：没它，SUM() OVER ()算的是全量和，不是累计 - 如果排序字段有重复值（如多个订单同秒下单），需加唯一键补位，否则累计顺序不确定：
ORDER BY create_time, order_id
把LEFT JOIN + 子查询的同比计算改成窗口函数，怎么写才不漏数据？
典型错误是直接套 LAG() 却忽略分区边界——比如按月统计销售额，但没加 PARTITION BY product_id，导致A产品数据被B产品的上月值覆盖。
- 同比/环比必须两级分区：
OVER (PARTITION BY product_id ORDER BY ym) -
LAG(sales, 1)返回上一行值，但若某产品某月缺数据，它会跳到更早的非空行；要严格按月对齐，得先用GENERATE_SERIES（PostgreSQL）或日期维表补全，再用窗口函数 - MySQL 8.0+ 支持
LAG()，但旧版只能用变量模拟，稳定性差，建议升级或改用应用层计算
窗口函数嵌套（比如RANK()里套SUM()）性能爆炸，怎么拆解？
数据库无法优化嵌套窗口，会强制物化中间结果，内存占用翻倍。真实场景中，90% 的嵌套需求其实可以扁平化。
- 避免
RANK() OVER (ORDER BY SUM(amount) OVER (...))这种写法；先用 CTE 算出SUM()，再在其结果上RANK() - PostgreSQL 中
WITH ORDINALITY配合UNNEST比嵌套窗口快得多；MySQL 则建议把最外层排序提到应用层 - 如果必须嵌套，确保内层窗口的
PARTITION BY和外层一致，否则优化器大概率放弃并行
WHERE条件误放在窗口函数后导致逻辑错乱，怎么排查？
WHERE 在窗口计算前执行，这是铁律。常见陷阱是写 SELECT *, SUM(x) OVER (...) AS s FROM t WHERE s > 100 —— 直接报错，因为 s 是计算列，不能进 WHERE。
- 过滤聚合结果必须用
HAVING（配合GROUP BY）或外层查询：SELECT * FROM (SELECT *, SUM(x) OVER (...) s FROM t) t2 WHERE s > 100 - 想过滤掉某些行再算窗口？必须把
WHERE写在子查询里，而不是窗口定义之后 - 部分人用
FILTER (WHERE ...)（PostgreSQL）代替子查询，但兼容性差，MySQL 不支持
复杂统计的可读性提升，本质是让 SQL 更贴近思考路径：先分组、再排序、最后算指标。窗口函数只是工具，真正容易被忽略的是——你有没有先画出数据流图，确认每一行在每个步骤的含义？
