SQL累加计算实战指南：窗口函数与4种高效方法解析

累加计算是数据分析中的核心需求，无论是计算累计销售额、用户访问量还是项目收益，都需要掌握高效的SQL实现方法。本文将详细拆解四种主流的SQL累加方法，并通过实例对比其优劣，帮助你根据不同的数据库环境与场景选择最佳方案。

一、基础数据准备

我们先创建一个简单的销售记录表作为后续演示的示例数据：

-- 创建销售记录表
CREATE TABLE #Sales (
    SaleDate DATE,          -- 销售日期
    ProductName VARCHAR(50), -- 产品名称
    DailySales DECIMAL(10,2) -- 日销售额
);

-- 插入测试数据
INSERT INTO #Sales VALUES
('2024-01-01', '产品A', 1000.00),
('2024-01-02', '产品A', 1500.00),
('2024-01-03', '产品A', 800.00),
('2024-01-04', '产品A', 2000.00),
('2024-01-01', '产品B', 500.00),
('2024-01-02', '产品B', 700.00),
('2024-01-03', '产品B', 1200.00);

-- 查看数据
SELECT * FROM #Sales ORDER BY ProductName, SaleDate;

二、方法1：使用自连接

在窗口函数普及之前，自连接是传统的累加实现方式。其原理是通过表的自关联，将当前行与所有日期更早或相等的行进行连接并求和。

-- 使用自连接计算每个产品的累计销售额
SELECT
    s1.ProductName,
    s1.SaleDate,
    s1.DailySales,
    SUM(s2.DailySales) AS CumulativeSales
FROM #Sales s1
INNER JOIN #Sales s2
    ON s1.ProductName = s2.ProductName  -- 按产品分组
    AND s2.SaleDate <= s1.SaleDate      -- 只累加当前日期及之前的销售
GROUP BY s1.ProductName, s1.SaleDate, s1.DailySales
ORDER BY s1.ProductName, s1.SaleDate;

查询结果示例：

缺点：当数据量较大时，自连接会产生大量的中间结果（接近笛卡尔积），导致查询性能急剧下降，不推荐在大数据场景下使用。

三、方法2：使用相关子查询

另一种传统方法是使用相关子查询，逻辑上更直观，但性能瓶颈更为明显。

-- 使用子查询计算累计销售额
SELECT
    s1.ProductName,
    s1.SaleDate,
    s1.DailySales,
    (
        SELECT SUM(s2.DailySales)
        FROM #Sales s2
        WHERE s2.ProductName = s1.ProductName
          AND s2.SaleDate <= s1.SaleDate
    ) AS CumulativeSales
FROM #Sales s1
ORDER BY s1.ProductName, s1.SaleDate;

缺点：对于结果集中的每一行，数据库都需要执行一次子查询来汇总数据。当表数据行数很多时，这种N+1的查询模式会带来巨大的性能开销。

四、方法3：使用窗口函数（推荐）

在现代主流数据库（如 SQL Server、PostgreSQL、MySQL 8.0+）中，窗口函数是处理累加、排名等分析需求的首选工具，尤其适合数据库与中间件中的复杂分析场景。它通过一次数据扫描即可完成计算，性能卓越。

-- 使用SUM() OVER()窗口函数计算累计销售额
SELECT
    ProductName,
    SaleDate,
    DailySales,
    SUM(DailySales) OVER (
        PARTITION BY ProductName         -- 按产品分组计算
        ORDER BY SaleDate                -- 按日期排序
        ROWS BETWEEN UNBOUNDED PRECEDING -- 从分区第一行开始
             AND CURRENT ROW             -- 累加到当前行
    ) AS CumulativeSales,
    -- 更简洁的写法：默认框架就是从第一行到当前行
    SUM(DailySales) OVER (
        PARTITION BY ProductName
        ORDER BY SaleDate
    ) AS CumulativeSales2  -- 结果与上面一致
FROM #Sales
ORDER BY ProductName, SaleDate;

窗口函数的三大核心优势：

1. 性能高效：仅需对数据进行单次扫描，避免了连接或多次子查询的开销。
2. 灵活可控：通过 PARTITION BY 定义分组，ORDER BY 定义顺序，并能用 ROWS/RANGE 子句精确控制累加范围（如最近3行、当前行前后范围等）。
3. 语法清晰：逻辑直接体现在 OVER() 子句中，代码可读性和可维护性更强。

五、方法4：使用CTE递归（特殊场景）

递归公用表表达式通常用于处理层次结构或序列生成。虽然不常用于简单的累加，但它适用于依赖前一行结果进行递推计算的场景。

-- 使用CTE递归计算斐波那契数列（演示递推逻辑）
WITH Fibonacci (n, a, b) AS (
    -- 锚点成员：定义序列起始值
    SELECT 1, 0, 1
    UNION ALL
    -- 递归成员：基于前一行(a,b)计算下一行的值(b, a+b)
    SELECT n + 1, b, a + b
    FROM Fibonacci
    WHERE n < 10  -- 设置递归深度，防止无限循环
)
SELECT n, b AS FibonacciNumber
FROM Fibonacci
ORDER BY n;

六、最佳实践与实战示例

累加计算最佳实践：

1. 首选窗口函数：SUM() OVER() 是现代SQL中性能与功能的最佳平衡。
2. 必须指定排序：ORDER BY 是决定累加顺序的关键，缺少它将导致不确定的结果。
3. 合理使用分区：PARTITION BY 用于分组独立累加，是数据分析中多维分析的基础。
4. 理解默认框架：当指定 ORDER BY 而未指定 ROWS/RANGE 时，默认框架为 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。了解 ROWS 和 RANGE 的区别对处理并列值很重要。

实战示例：计算销售排行榜累计占比

以下示例结合了窗口函数的多种用法，实现一个带排名和累计占比的分析报表：

-- 按产品总销售额排名，并计算累计占比
WITH ProductSales AS (
    SELECT
        ProductName,
        SUM(DailySales) AS TotalSales
    FROM #Sales
    GROUP BY ProductName
),
RankedProducts AS (
    SELECT
        ProductName,
        TotalSales,
        ROW_NUMBER() OVER (ORDER BY TotalSales DESC) AS Rank,
        SUM(TotalSales) OVER (ORDER BY TotalSales DESC) AS CumulativeSales,
        SUM(TotalSales) OVER () AS GrandTotal
    FROM ProductSales
)
SELECT
    ProductName,
    TotalSales,
    Rank,
    CumulativeSales,
    CAST(CumulativeSales * 100.0 / GrandTotal AS DECIMAL(5,2)) AS CumulativePercentage
FROM RankedProducts
ORDER BY Rank;

总结

SQL累加计算是数据处理的必备技能。从传统的自连接、子查询，到现代的窗口函数和递归CTE，每种方法都有其适用场景。对于绝大多数数据分析和报表需求，SUM() OVER() 窗口函数凭借其优异的性能和强大的表达能力，已成为行业标准做法。掌握其 PARTITION BY（分组）、ORDER BY（排序）、窗口框架（范围）这三个核心要素，你就能高效解决各类累计计算问题。