窗口函数累计必须按日期字段排序且用ROWS模式，否则累计乱序；sale_date需为DATE/TIMESTAMP类型，同日多记录应追加唯一字段排序，并优先聚合后开窗提升性能与准确性。
窗口函数里 ORDER BY 必须包含时间字段，否则累计不按天生效
很多人写 SUM(sales) OVER (ORDER BY order_id)，结果发现累计值乱序——根本原因是没把日期字段放进 ORDER BY。窗口函数的累计逻辑完全依赖排序依据，order_id 和销售日期通常不一致，会导致“按订单号累计”而非“按天累计”。
正确做法是显式用日期字段排序，且最好加上 date 或 sale_date（注意别用字符串类型，否则可能隐式排序出错）：
SELECT sale_date, sales, SUM(sales) OVER (ORDER BY sale_date ROWS UNBOUNDED PRECEDING) AS cum_sales FROM sales_table;
-
sale_date必须是 DATE 或 TIMESTAMP 类型；若存为字符串（如'2024-03-15'），需先CAST(sale_date AS DATE) - 如果同一天有多条记录，仅靠
ORDER BY sale_date无法保证稳定排序，建议追加唯一字段：ORDER BY sale_date, id -
ROWS UNBOUNDED PRECEDING是默认行为，可省略，但显式写出更清晰、避免误用RANGE模式
RANGE 和 ROWS 在按天累计时表现完全不同
默认的 ORDER BY 窗口框架是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，它对相同排序值的行“一视同仁”。如果某天有 3 笔销售，RANGE 模式会让这 3 行的累计值都等于当天及之前所有天的总和——看起来没问题，但一旦需要“逐行累计”（比如看每笔订单的当日累计），就出错了。
真正按“天粒度累加、但保留每行独立值”的场景，必须用 ROWS：
SUM(sales) OVER ( ORDER BY sale_date, id ROWS UNBOUNDED PRECEDING )
-
RANGE：对sale_date相同的所有行，累计值一样（适合日汇总后展示） -
ROWS：严格按排序顺序逐行累加，同一日多笔记录会呈现递增累计（适合订单流分析） - PostgreSQL 默认用
RANGE，MySQL 8.0+ 和 SQL Server 默认用ROWS，别假设一致
跨月/跨年累计时，sale_date 字段必须可比较，不能是文本格式
常见坑：表里 sale_date 实际是 VARCHAR，存成 '2024/03/15' 或 '15-Mar-2024'。这种字段即使看着有序，ORDER BY 也会按字符串字典序排——'2024/01/01' 会排在 '2024/12/31' 后面，导致累计完全错乱。
- 检查类型：
SELECT pg_typeof(sale_date) FROM sales_table LIMIT 1（PostgreSQL）或DESCRIBE sales_table（MySQL） - 临时修复：
CAST(sale_date AS DATE)或STR_TO_DATE(sale_date, '%Y/%m/%d')（MySQL） - 长期方案：建表时用
DATE类型，导入数据前清洗格式 - 别依赖
TO_CHAR或FORMAT函数做排序依据——它们输出的是字符串
想按自然日分组再累计？先聚合再开窗更稳
如果原始数据是每笔订单一行，但你只需要“每天一个累计值”，直接在明细层开窗容易重复计算（比如某天 100 笔订单，窗口函数执行 100 次）。更合理的方式是先按天聚合，再对聚合结果开窗：
WITH daily_sum AS (
SELECT
sale_date,
SUM(sales) AS daily_sales
FROM sales_table
GROUP BY sale_date
)
SELECT
sale_date,
daily_sales,
SUM(daily_sales) OVER (ORDER BY sale_date) AS cum_sales_by_day
FROM daily_sum;
- 减少窗口函数执行次数，尤其数据量大时性能差异明显
- 避免因同一天多行导致的语义混淆（比如“当日第 3 笔订单的累计” vs “当日总销售额的累计”）
- 如果业务要求保留明细行又需日级累计，可用
MAX() OVER (PARTITION BY sale_date)先取当日总和，再累加
SELECT sale_date, COUNT(*) FROM sales_table GROUP BY sale_date ORDER BY sale_date 看看日期分布是否连续、有没有空洞——窗口函数不会自动补 0，缺哪天，累计就断在哪天。 
