滚动销量不能用GROUP BY+SUM，因会丢失日期粒度；必须用窗口函数SUM() OVER(ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)实现7日滚动求和。
滚动销量为什么不能用 GROUP BY + SUM？
因为 GROUP BY 会把多天数据聚合成一行，丢失日期粒度；而滚动销量必须保留每天一条记录，并带上「截至当天的最近7天总销量」。窗口函数是唯一能同时保留原始行、又跨行计算的方案。
典型错误写法：SELECT date, SUM(sales) FROM orders GROUP BY date —— 这只能算单日销量，没法回溯前6天。
正确思路：按日期排序，用 SUM() OVER () 定义一个向前滑动7天的窗口。
SQL写法：用 ROWS BETWEEN 定义7日滚动窗口
关键不是简单套 SUM(sales) OVER ()，而是必须显式指定窗口边界，否则默认是 UNBOUNDED PRECEDING（从第一行开始），会导致首日就累加全量数据。
- 正确写法：
SUM(sales) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) -
6 PRECEDING表示包含当前行往前6行（共7天），注意不是7 PRECEDING - 日期字段必须严格连续——如果某天无销售记录，该日不会出现在结果中，窗口会“跳过”这一天，导致实际跨度不足7日
- 若需强制补全缺失日期，得先用
GENERATE_SERIES（PostgreSQL）或递归CTE（MySQL 8.0+）生成日期维度表再 LEFT JOIN
MySQL 8.0 vs PostgreSQL 的兼容性差异
两者语法基本一致，但两个细节容易出错：
- MySQL 不支持
ROWS BETWEEN ... AND CURRENT ROW中的CURRENT ROW缩写（如写成CURRENT ROW没问题，但别漏掉）；PostgreSQL 允许省略CURRENT ROW，但建议显式写出，避免歧义 - PostgreSQL 支持
DATE类型直接参与ORDER BY，MySQL 若字段是DATETIME或带时分秒，需先DATE(order_time)提取日期，否则同一天内多条记录排序不稳定，影响窗口边界 - 性能上：窗口函数在大表上依赖
date字段有索引，否则ORDER BY date会触发 filesort，千万级订单表务必确认INDEX(date)存在
真实餐饮场景下的数据清洗陷阱
线上订单表常含干扰项：退单、测试单、未支付单。直接对 sales 求和会高估滚动销量。
- 务必过滤状态：
WHERE status = 'paid' AND is_test = 0 - 注意菜品粒度：如果原始表是订单主表（每行一个订单），需先
JOIN order_items展开为「每行一道菜」，再按date和dish_id分组求当日销量，最后套窗口函数 - 时间口径要统一：前端展示「每日销量」通常指下单时间，不是支付时间或配送时间——确认业务方定义，避免和BI报表对不上
- 滚动窗口结果不能用于实时告警阈值判断：因为第1–6天的窗口长度不足7，数值偏低，需额外加
CASE WHEN COUNT(*) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) 做校验
滚动销量不是算得快就行，关键是每一步都贴着业务规则走；少一个 WHERE 条件，或者没处理退单，后面所有分析都会漂移。
