MySQL 8.0+支持SUM()窗口函数，基本写法为SUM(column) OVER (ORDER BY key_column)，必须含ORDER BY，可选PARTITION BY；默认帧为ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，实现累计求和；不可与GROUP BY混用，需靠PARTITION BY分组；注意NULL处理、排序字段唯一性及索引优化。
MySQL SUM窗口函数的基本写法
MySQL 8.0+ 才支持 SUM() 窗口函数，低于这个版本直接报错 FUNCTION xxx does not exist。必须确保 ORDER BY 存在，否则累计逻辑无意义，且会报错 This function requires an ORDER BY clause。
基本结构是：SUM(column) OVER (ORDER BY key_column)，其中 key_column 通常是时间戳、ID 或其他能定义“先后顺序”的字段。
- 不加
PARTITION BY：全表按排序顺序累计 - 加
PARTITION BY category：每个分类内独立累计（比如按用户、按月份） - 不能只写
OVER ()—— 这不是聚合函数，空窗口定义非法
累计值 vs 当前行求和的常见误解
很多人以为 SUM(amount) OVER (ORDER BY id) 是“从第一行加到当前行”，这没错；但容易忽略默认的 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 行帧（frame）定义 —— 它才是累计行为的真正来源。
如果显式改写成 SUM(amount) OVER (ORDER BY id ROWS BETWEEN CURRENT ROW AND CURRENT ROW)，结果就变成每行只算自己，不再是累计。
- 默认 frame 是安全的，适合大多数累计场景
- 若需“截止上一行”的累计（即排除当前行），得手动写
ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING - MySQL 不支持
RANGE帧中用INTERVAL（如RANGE BETWEEN INTERVAL 7 DAY PRECEDING AND CURRENT ROW），别试
与 GROUP BY 混用时的典型错误
想先分组再累计？比如“每个用户的每日销售额 + 用户内累计”。这时不能写 GROUP BY user_id, sale_date 后再套窗口函数 —— GROUP BY 会压缩行数，窗口函数没机会逐行计算。
正确做法是：先用窗口函数算累计，再在外层 GROUP BY 聚合（如果真需要），或更常见的是——根本不用 GROUP BY，靠 PARTITION BY user_id ORDER BY sale_date 实现分组内累计。
- 错误示例：
SELECT user_id, SUM(sale) AS daily_total, SUM(sale) OVER (ORDER BY sale_date) FROM t GROUP BY user_id, sale_date→ 报错或结果错乱 - 正确示例：
SELECT user_id, sale_date, sale, SUM(sale) OVER (PARTITION BY user_id ORDER BY sale_date) AS cumsum FROM t - 注意：如果
sale_date有重复，需补上二级排序字段（如id），否则累计顺序不确定
性能和 NULL 处理的实际影响
SUM() 窗口函数自动跳过 NULL 值，这点和普通 SUM() 一致。但要注意：如果排序字段是 NULL，MySQL 会把它们排在最前面（ASC 时），可能导致累计起点异常。
性能方面，窗口函数依赖排序，大数据量下 ORDER BY 字段必须有索引，否则执行计划里会出现 Using filesort，IO 和 CPU 开销陡增。
- 推荐组合索引：
(user_id, sale_date, sale)（用于PARTITION BY user_id ORDER BY sale_date） - 用
EXPLAIN ANALYZE确认是否走索引扫描，而非全表 + 排序 - 避免在窗口函数里嵌套复杂子查询或函数（如
SUM(ROUND(price * tax_rate)) OVER (...)），会显著拖慢
实际业务中，累计值常要和原始明细共存展示，所以几乎总是搭配 SELECT * 使用；而最容易被忽略的，是排序字段的唯一性和索引覆盖 —— 这两点一旦出问题，结果可能偶尔对、偶尔错，排查起来特别花时间。
