SQL中SUM()加OVER能算组内累计和，因为OVER子句定义窗口范围，默认ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，使SUM在每行累加分区起点至当前行的值；关键依赖显式、稳定的ORDER BY，缺之则结果不可靠或不一致；漏写PARTITION BY会导致全表误作单组计算。
SQL中SUM()加OVER为什么能算组内累计和
因为OVER子句定义了窗口范围，配合SUM()就能在每行“看到”从分区起点到当前行（默认ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW）的所有值之和。关键不是SUM本身，而是ORDER BY是否明确——没它，累计和结果不可靠，甚至可能每次执行都不一样。
-
ORDER BY必须存在且语义稳定（比如用时间戳或自增ID，别用无序的name） - 如果漏写
PARTITION BY，整个结果集会被当成一个组，不是“组内”累计 - 某些旧版MySQL（ERROR 1064
按用户分组、按时间排序的累计订单金额怎么写
这是最常见场景：每个用户独立累计，且按下单时间从前到后累加。重点是PARTITION BY user_id + ORDER BY order_time组合，缺一不可。
SELECT
user_id,
order_time,
amount,
SUM(amount) OVER (
PARTITION BY user_id
ORDER BY order_time, order_id -- 加order_id防时间重复时排序不稳定
) AS cum_amount
FROM orders;- 若
order_time有重复，仅靠它排序会导致同一时间的多笔订单累计顺序不确定，加order_id可破歧义 - 别用
ORDER BY order_time DESC来倒序累计——那算的是“从最后一条往前累加”，不符合常规理解 - PostgreSQL/SQL Server/Oracle都支持；SQLite需3.25+，且
OVER里不能省略ORDER BY
SUM() OVER和自连接/子查询实现累计和的区别在哪
开窗函数是单次扫描、线性时间复杂度；而自连接或相关子查询是N²级，数据量一过万就明显变慢。另外，开窗函数天然支持PARTITION BY，子查询要靠WHERE模拟分组逻辑，容易出错。
- 子查询写法示例（不推荐）：
(SELECT SUM(t2.amount) FROM orders t2 WHERE t2.user_id = t1.user_id AND t2.order_time - 当
user_id和order_time没有联合索引时，子查询几乎必全表扫描；开窗函数即使没索引，也只扫一遍 - 开窗函数无法直接替代“截止到上一行”的需求（如排除当前行），得改用
ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING
累计和结果突然跳变为NULL或0，可能是什么原因
通常不是语法错，而是数据本身触发了隐式类型转换或空值传播。特别是当amount字段为NULL时，SUM()在窗口中遇到NULL会跳过，但若整组全是NULL，结果就是NULL——看起来像“断掉”了。
- 检查源字段是否允许
NULL：SELECT COUNT(*) FROM orders WHERE amount IS NULL - 安全写法：用
COALESCE(amount, 0)包裹再求和，避免空值干扰累积逻辑 - 某些数据库（如老版本Hive）对
ORDER BY列含NULL行为不一致，建议提前WHERE amount IS NOT NULL过滤或ORDER BY COALESCE(order_time, '1970-01-01')
累计和看着简单，但ORDER BY的确定性、NULL的处理、以及不同数据库对ROWS框架的默认支持程度，才是实际跑起来卡住的地方。
