MySQL 8.0累计求和必须用SUM() OVER()，且必须显式指定ORDER BY；默认帧为ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，实现从首行到当前行的逐行累加，不可与GROUP BY混用，需靠PARTITION BY分组。
MySQL 8.0 窗口函数 cumulative sum 必须用 SUM() OVER()
MySQL 8.0 开始原生支持窗口函数，但不能用 GROUP BY 模拟累计和——那样只能得到分组汇总，丢失原始行级明细。真正做累计加和，唯一可靠方式是 SUM() OVER()，且必须显式定义窗口帧（frame）或依赖默认行为。
常见错误是直接写 SUM(amount) 不加 OVER，结果报错 ERROR 1140: In aggregated query without GROUP BY；或者写了 OVER() 却没指定排序，导致累计值顺序混乱、结果不可复现。
-
ORDER BY是强制的：累计和依赖行序，OVER(ORDER BY date)中的date必须存在且无重复（或搭配ROW_NUMBER()消除并列） - 默认帧是
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，即从第一行累加到当前行，无需额外写 - 若想排除当前行（如“截至上一日的累计”），需显式写
ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING
按日期分组再累计：先 GROUP BY 再套窗口函数
原始数据是逐笔订单，但业务要的是“每日销售额的累计值”，这时不能在原始表上直接 OVER(ORDER BY date)——同一天多笔记录会导致该日出现多个重复累计值。正确做法是两层结构：外层窗口函数作用于聚合后的日粒度结果。
SELECT day, daily_sum, SUM(daily_sum) OVER (ORDER BY day) AS cumsum FROM ( SELECT DATE(created_at) AS day, SUM(amount) AS daily_sum FROM orders GROUP BY DATE(created_at) ) t;
注意内层 GROUP BY 的 DATE(created_at) 必须和外层 ORDER BY day 一致，否则窗口排序失效；若 day 有空值，会排在最前，可能污染累计起点，建议加 WHERE day IS NOT NULL 过滤。
ROWS vs RANGE 帧类型影响累计逻辑
默认帧类型是 ROWS，按物理行序计算；若误用 RANGE（如 SUM(x) OVER (ORDER BY date RANGE BETWEEN ...)），当多行 date 相同时，它们会被视为同一“范围”，累计值会在这些行上重复输出相同结果——不是 bug，是设计如此，但常被误认为计算错误。
- 业务要求“每个时间点独立累计” → 用
ROWS（默认，安全） - 业务要求“按值分桶累计”（如所有 2023-01-01 的记录共享一个累计值）→ 才考虑
RANGE，但 MySQL 对RANGE数值类型限制严格，日期字段不支持直接用于RANGE，会报错ERROR 3586: Window 'w' with RANGE frame requires exactly one ORDER BY column of numeric type - 所以对日期/字符串字段，坚持用
ROWS，别碰RANGE
性能敏感场景：避免在大表上无索引 ORDER BY
SUM() OVER(ORDER BY ...) 的执行计划里，MySQL 通常需要临时文件排序。如果 ORDER BY 字段没有索引，100 万行以上就可能明显变慢，甚至 OOM。
- 确认执行计划中
Extra字段是否含Using filesort；若有，且该字段高频用于累计计算，应建索引 - 例如：
CREATE INDEX idx_orders_date ON orders(date);（假设按date累计） - 复合场景如
ORDER BY dept_id, date，需创建联合索引(dept_id, date)，顺序不能颠倒 - 窗口函数无法利用索引做“下推过滤”，
WHERE条件仍需在窗口计算前完成，所以先WHERE再OVER更高效
