说说Oracle里那些分析函数到底怎么用，实际场景下能帮啥忙

说到Oracle里的分析函数,你可以把它们想象成SQL查询里的“超级武器”，普通的聚合函数，比如SUM、AVG，只能把多行数据揉成一团，最后给你一个总的结果，但分析函数不一样，它能在给你每一行明细数据的同时，还附带上基于某个范围计算出来的统计值，有点像“透视”着看数据。

举个最接地气的例子：排名问题。

想象你是一个销售经理,手里有一张全年的销售记录表，你想知道每个销售员在每个月的销售额，并且还想知道这个销售员这个月的业绩在部门里排第几名。

用普通SQL怎么做？你可能得先分组算出每个人的月销售额，然后再用子查询或者自连接去笨拙地计算排名，写起来又长又容易出错。

但用分析函数,一句就搞定了：

SELECT
   销售员,
   月份,
   销售额,
   RANK() OVER (PARTITION BY 部门, 月份 ORDER BY 销售额 DESC) as 部门内排名
FROM 销售记录表;

这句SQL的关键就在RANK() OVER这部分。OVER是分析函数的灵魂，它定义了计算的范围和规则：

• PARTITION BY 部门, 月份：意思是说，排名不是在整个公司里乱排，而是先在“部门”内部，再在同一个“月份”内部进行分组，你可以把它理解成“开窗口”，给每个部门每个月的组合都开一个独立的小窗口，排名只在这个小窗口里生效。
• ORDER BY 销售额 DESC：在每个小窗口里，按照销售额从高到低排序，然后决定名次。

这样,查询结果里，每一行数据除了原本的销售员、月份、金额，还会多出一列“部门内排名”，清清楚楚，这就是分析函数的威力：数据明细和统计结果同时呈现，互不影响。

再来看一个更实用的场景：比较相邻时间段的数据。

还是销售的例子,老板想知道每个产品这个月的销售额比上个月是增长了还是下降了，具体差多少。

这个用普通SQL非常难写,可能需要把表自连接，或者写复杂的子查询，但用LAG这个分析函数就简单多了：

SELECT
   产品ID,
   月份,
   本月销售额,
   LAG(本月销售额, 1) OVER (PARTITION BY 产品ID ORDER BY 月份) as 上月销售额,
   本月销售额 - LAG(本月销售额, 1) OVER (PARTITION BY 产品ID ORDER BY 月份) as 环比增长额
FROM 月销售表;

LAG函数的意思是“向前翻看”。LAG(本月销售额, 1)就是看同一产品（PARTITION BY 产品ID）在上一个月（ORDER BY 月份，然后往前数1行）的销售额是多少，这样，我们就能轻松地在本月数据行旁边，列出上月的数，并计算出差额。

对应的还有LEAD函数，是“向后看”，可以用来计算“本月和下月的差额”。

还有一个高频场景：累加问题。

财务人员可能想知道,截止到当前月份，每个产品的年度累计销售额是多少。

这用SUM配合OVER就能实现：

SELECT
   产品ID,
   月份,
   本月销售额,
   SUM(本月销售额) OVER (PARTITION BY 产品ID ORDER BY 月份) as 年度累计销售额
FROM 月销售表;

这个SUM不再是分组汇总了，而是“按产品分区，按月份排序后，从第一个月累加到当前月”的累计和，这对于做财务报表、增长趋势分析极其方便。

分析函数在实际工作中到底能帮啥忙：

1. 简化复杂查询：以前需要多次查询、自连接或复杂子查询才能解决的问题，现在一句SQL就能搞定，代码更简洁，执行效率也往往更高。
2. 实现高级排名和窗口计算：比如部门内排名、同级比较（和第一名的差距）、移动平均（比如计算最近三个月的平均销售额）等，这些都是业务分析中的常见需求。
3. 进行数据对比和趋势分析：像上面提到的环比、同比、累计计算，分析函数是天然利器，能让你轻松洞察数据的变化规律。
4. 避免使用效率低下的自连接：在很多情况下，用分析函数替代自连接查询，数据库的优化器能生成更优的执行计划，大大提升大数据量下的查询速度。

Oracle的分析函数（其他现代数据库如MySQL 8.0+、PostgreSQL也支持类似功能）不是用来炫技的，而是实实在在提升数据分析效率和能力的工具，一旦你用熟了OVER (PARTITION BY ... ORDER BY ...)这个核心句式，就会发现很多之前觉得棘手的数据分析问题，突然变得迎刃而解了。