相关子查询可模拟累计求和，但需明确排序字段并建索引，否则性能差且结果不可靠；推荐优先使用窗口函数sum() over(order by ...)，mysql 5.7等旧版本可用用户变量临时替代。
子查询实现累计求和的典型写法
SQL标准语法里没有内置的累计函数（如SUM() OVER()这种窗口函数），但用相关子查询可以模拟出来。核心思路是：对每一行，用子查询计算“从第一行到当前行”的某列总和。
常见错误是忽略排序依据——累计值必须基于明确的顺序，否则结果不可靠。比如按时间、ID或序号字段排序，否则子查询返回的“前N行”是随机的。
示例（以订单表orders为例，按order_date累计金额）：
SELECT order_id, order_date, amount, (SELECT SUM(amount) FROM orders o2 WHERE o2.order_date <p>注意：<code>o1</code>和<code>o2</code>是表别名，用于区分外层和内层查询；<code>保证包含当前行本身。</code></p> <h3>性能差在哪？为什么不能直接套用</h3> <p>相关子查询本质是“每行执行一次子查询”，数据量大时会严重拖慢。1万行数据可能触发1万次全表扫描（除非有合适索引）。</p> <p>容易踩的坑：</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/ai/1644" title="Regie.ai"><img src="https://img.php.cn/upload/ai_manual/000/969/633/68b6d7fb5f8ca196.png" alt="Regie.ai" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/ai/1644" title="Regie.ai" class="overflowclass">Regie.ai</a> <p class="overflowclass">一款面向销售团队的 AI 销售内容与沟通平台，帮助企业生成个性化销售文案、客户触达内容并辅助开展规模化外呼和拓客工作。</p> </div> <a rel="nofollow" href="/ai/1644" title="Regie.ai" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
- 没给排序字段建索引——
WHERE o2.order_date 无法走索引范围扫描 - 用
!=或代替<code>，导致当前行被漏掉 - 多字段排序时没在子查询中严格复现排序逻辑（比如
order_date, order_id组合排序，子查询只比order_date）
MySQL 8.0+ 或 PostgreSQL 推荐改用窗口函数
如果数据库支持窗口函数（MySQL ≥ 8.0，PostgreSQL ≥ 8.4，SQL Server ≥ 2005），直接用SUM() OVER()更安全高效：
SELECT order_id, order_date, amount, SUM(amount) OVER (ORDER BY order_date, order_id) AS cum_amount FROM orders;
关键点：
-
ORDER BY必须明确，否则OVER()默认按无序处理，累计结果不稳定 - 多个排序字段要和业务逻辑一致，比如同一天多笔订单需用
order_id保序 - 不加
PARTITION BY就是全局累计；加了就分组累计（如按用户ID分组）
兼容老版本 MySQL（5.7 及更早）的替代方案
MySQL 5.7 不支持窗口函数，又不想用低效子查询？可以用变量模拟：
SET @cum := 0; SELECT order_id, order_date, amount, (@cum := @cum + amount) AS cum_amount FROM orders ORDER BY order_date, order_id;
但要注意：
- 必须先
SET初始化变量，且ORDER BY必须写在查询末尾（MySQL执行顺序敏感） - 不能在子查询或视图里用变量，MySQL 5.7 中变量行为未定义
- 并发查询下变量可能被干扰，仅限单线程脚本或临时分析使用
真正上线的系统里，这类变量写法风险高，不如升级数据库或预计算存到冗余字段。
