PostgreSQL窗口函数，很多人一听名字就头大。
觉得那是数据库专家才玩的高深把戏。
其实说白了，它就是SQL里的“瑞士军刀”。
不用自连接，不用子查询嵌套，就能搞定那些让人头疼的排名、累计求和、同比环比。
今天咱们不聊枯燥的理论，直接上干货。
看看怎么用这几行代码，把复杂的数据分析变得像呼吸一样简单。
告别自连接，排名不再痛苦
想象一下这个场景。
你要找出每个部门里工资最高的前三名员工。
如果用传统的写法，你得先分组取最大值，再关联回原表过滤。
代码写得自己都晕，性能还差得离谱。
窗口函数 RANK() 或者 DENSE_RANK() 一出，问题迎刃而解。
SELECT
department,
employee_name,
salary,
RANK() OVER (PARTITION BY department ORDER BY salary DESC) as rank_in_dept
FROM employees;
就这么简单。
PARTITION BY 就像给你的数据切蛋糕，按部门分块。
ORDER BY 是在每一块蛋糕里排座次。
注意哦，RANK() 遇到并列第一，下一个就是第三名。
如果你想要紧凑排名，比如两个第一后是第二，那就用 DENSE_RANK()。
这两种细微差别，在实际业务报表里经常搞混。
搞清楚它，能省下你调试半天的时间。
累计求和：实时看板的神器
做电商数据分析的朋友肯定遇到过这种需求。
计算每天的销售总额，还要加上之前所有天的累计销售额。
以前怎么做？
写一个复杂的子查询，或者用存储过程循环累加。
现在有了 SUM() OVER (...)，一行代码搞定。
SELECT
sale_date,
daily_amount,
SUM(daily_amount) OVER (ORDER BY sale_date) as cumulative_total
FROM sales;
这里的关键在于没有 PARTITION BY。
这意味着整个结果集被看作一个大整体，按日期顺序一直加下去。
这就是所谓的“滚动累计”。
在做财务对账或者用户增长趋势图时，这个功能简直是救命稻草。
它比任何编程语言里的循环都要快得多。
因为PostgreSQL在引擎层做了优化，利用了内存中的状态机。
你只需要关注逻辑，不需要操心性能瓶颈。
前后对比：轻松实现环比增长
除了累计，还有一个高频场景：看当前行和上一行的差异。
比如计算每个月的增长率，或者判断股价是涨是跌。
这时候，LAG() 和 LEAD() 函数就派上用场了。
LAG(col, n) 获取前 n 行的值。
LEAD(col, n) 获取后 n 行的值。
假设你要算本月相对于上月的销售额变化：
SELECT
month,
sales,
LAG(sales, 1) OVER (ORDER BY month) as prev_month_sales
FROM monthly_reports;
拿到上个月的数据后，你在应用层做个除法，或者直接在SQL里套一层计算：
(sales - LAG(sales) OVER (ORDER BY month)) * 100.0 / LAG(sales) OVER (ORDER BY month)
这样你就能直接得到增长率百分比。
不用再去关联一张自己的表。
这种写法在处理时间序列数据时，清晰度提升了不止一个量级。
特别是当你需要看“未来预测”或者“滞后效应”时，LEAD() 同样好用。
平均值去极值：更真实的统计视角
有时候，平均数会骗人。
比如某公司全员平均工资很高，是因为CEO年薪太高拉高了均值。
这时候你需要去掉极端值后的平均值。
可以用 AVG() 配合 ROWS BETWEEN 来控制范围。
但更高级的玩法，是利用 NTILE() 将数据分成若干份，然后取中间部分的平均值。
或者，直接使用 PERCENTILE_CONT() 百分位函数。
这在风控模型里特别常见。
我们要看的是“典型用户”的行为，而不是被少数异常值带偏的趋势。
窗口函数允许你在聚合的同时保留明细行。
这是普通 GROUP BY 做不到的。
GROUP BY 会把多行合并成一行，信息丢失了。
窗口函数则是给每一行都挂上一个“标签”，原始数据完整保留。
这使得你可以基于聚合结果进行二次筛选。
比如：“找出那些个人消费额高于该品类平均水平的用户”。
这句逻辑用传统SQL写起来极其啰嗦。
用窗口函数，只需要在 WHERE 子句外层包一层即可。
实战中的性能陷阱
当然，工具再好，也得会用。
窗口函数虽然强大，但也不是银弹。
如果 PARTITION BY 后面的列没有索引，或者数据量极大，排序开销会很重。
记得在分区列和排序列上建立合适的复合索引。
另外，避免在窗口函数的 ORDER BY 中使用非确定性函数。
比如 ORDER BY RANDOM()，这会导致每次执行结果都不一样，还会引发全表扫描式的排序。
还有，不要滥用 OVER ()。
如果没有明确的分区和排序，PostgreSQL会对整个结果集进行排序，这在大数据量下是灾难性的。
明确界定你的数据范围，是写好高性能SQL的第一步。
结语
PostgreSQL的窗口函数，其实是关系型数据库向现代数据分析靠拢的标志。
它让SQL具备了类似Python Pandas的处理能力。
掌握它，你就少写了无数行样板代码。
下次遇到排名、累计、对比这类需求，别急着写存储过程。
试试窗口函数，你会发现新世界的大门已经打开。