SQL嵌套查询累计求和（无窗口函数）

自连接模拟累计求和，简单说就是针对当前行，把所有排序位置不大于它的记录数值累加起来。这要求有一个明确的排序字段（比如id或order_date），而且该字段最好是唯一的——一旦出现重复值，就必须再搬一个唯一主键出来兜底排序。在MySQL 5.7这类没有窗口函数的旧版本里，这招是通用做法。

用自连接模拟累计求和的原理

没有窗口函数时，累计求和本质上是：对当前行，把所有满足“排序位置 ≤ 当前行”的记录的数值加起来。通过JOIN把表和自身按顺序条件关联就能实现——比如按时间或ID排序后，左表的每行去匹配右表中“ID小于等于它”的所有行。

关键点很明确：必须有唯一的排序字段（如id、order_date），且值不能重复，否则会多算；如果实在避免不了重复，就得搭配额外的唯一字段（比如自增主键）做保底排序。

MySQL 5.7 / PostgreSQL 9.5 等旧版本实操写法

假设有一张销售表sales，含字段id（递增）、amount（单笔金额），目标是按id顺序计算累计金额：

SELECT s1.id, s1.amount,       SUM(s2.amount) AS cumulative_amountFROM sales s1JOIN sales s2 ON s2.id <= s1.idGROUP BY s1.id, s1.amountORDER BY s1.id;

这里有三点需要注意：

• GROUP BY必须包含所有非聚合列（s1.id, s1.amount），否则MySQL 5.7+的严格模式会报错Expression #2 of SELECT list is not in GROUP BY clause。
• 如果id不连续（比如删过数据），逻辑上不影响，只影响“顺序”是否符合业务预期。
• 性能会随着数据量增长急剧下降——N行输入大约引发N次比较，数据量上万就要警惕了。

处理重复时间戳或并列排序的补救方法

当排序依据是order_date且存在多条同一天记录时，直接写s2.order_date <= s1.order_date会导致同天数据互相全量累加，结果偏大。

稳妥的做法是引入唯一辅助排序字段（比如自增id）：

SELECT s1.id, s1.amount, s1.order_date,       SUM(s2.amount) AS cumulative_amountFROM sales s1JOIN sales s2   ON s2.order_date < s1.order_date   OR (s2.order_date = s1.order_date AND s2.id <= s1.id)GROUP BY s1.id, s1.amount, s1.order_dateORDER BY s1.order_date, s1.id;

这个条件拆成两部分：小于日期 + 等于日期但 id 更小或相等，确保严格保序。

Oracle 11g 或 SQL Server 2008 的兼容性提醒

上述写法在这些数据库里基本可用，但要注意：

• SQL Server对JOIN条件中的不等式（<=）支持良好，但若表没有索引，执行计划容易走嵌套循环，速度会非常慢。
• Oracle中如果用ROWNUM伪列替代id，行不通——ROWNUM是结果集生成时才分配的，无法用于自连接中的稳定排序依据。
• 所有场景下，务必给排序字段建索引，例如CREATE INDEX idx_sales_order_date_id ON sales(order_date, id);

真正麻烦的是数据量超过10万行还硬扛这种写法——这会儿已经不是语法问题了，是得去说服业务方接受分页累计，或者升级数据库版本，用SUM() OVER (ORDER BY ...)彻底解放生产力。