窗口函数无需GROUP BY即可保留明细行，通过OVER子句实现分组聚合与原始数据并存，输出行数恒等于输入行数，避免子查询嵌套与性能损耗。
窗口函数不用 GROUP BY 就能保留明细行
传统报表统计一遇到“既要分组聚合，又要看到每条原始数据”，就得靠子查询或自连接硬扛。比如查每个部门的平均工资，同时显示每个人工资和差额，GROUP BY 会把人“压扁”成一行，再想回填明细就得嵌套一层又一层。窗口函数直接绕过这一步：SUM(salary) OVER (PARTITION BY dept_id) 算出部门平均值后，结果仍是一行一人，字段可并列存在。
- 关键区别：聚合函数输出行数 ≤ 输入行数；窗口函数输出行数 = 输入行数
- 典型误用：在
SELECT里混用GROUP BY和窗口函数，导致语法报错或逻辑错乱 - 性能影响：避免多次扫描同一张表，尤其在大表上，单次扫描 + 流式计算比 N 层子查询快得多
RANK()、ROW_NUMBER() 这类排名函数不依赖用户变量
MySQL 5.7 及之前版本做分组内排名，基本靠 @rownum 变量 + ORDER BY 排序模拟，但变量执行顺序不稳定，容易在并发或优化器重排时出错——同一 SQL 多次执行结果可能不一致。
-
RANK() OVER (PARTITION BY category ORDER BY score DESC)是确定性行为，结果严格按分区+排序定义 -
ROW_NUMBER()和RANK()的差异必须明确：ROW_NUMBER()强制唯一编号，RANK()相同值占位并跳号（如 1,2,2,4） - 常见坑：漏写
ORDER BY—— 没排序的RANK()结果是未定义的，MySQL 不报错但结果不可信
LAG()/LEAD() 替代自连接实现环比/同比
查“本月销售额 vs 上月销售额”，老办法是把销售表自连接两次，用日期偏移匹配，SQL 长、JOIN 开销大、索引难利用。用 LAG(amount, 1) OVER (PARTITION BY product_id ORDER BY sale_date)，数据库在一次有序扫描中就拿到前一行值。
-
LAG()取前 N 行，LEAD()取后 N 行，N 默认为 1 - 必须配合
ORDER BY，否则“前后行”无意义；若日期有重复，需加二级排序（如ORDER BY sale_date, id）避免非确定性 - 注意 NULL：首行调用
LAG()返回 NULL，业务逻辑里得显式处理，不能直接参与计算
SUM() OVER 配合 ROWS 框架算累计值更可控
SUM(amount) OVER (ORDER BY date) 默认等价于 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，即从第一行累加到当前行。但有些场景要限制范围，比如“最近 7 天滚动销售额”，就得显式写框架：
SUM(amount) OVER ( PARTITION BY store_id ORDER BY sale_time ROWS BETWEEN 6 PRECEDING AND CURRENT ROW )
-
ROWS按物理行数定位，RANGE按排序值范围定位（如金额区间），多数时间用ROWS更直观 - 漏写
PARTITION BY会导致跨门店/用户累加，数据污染不易察觉 - 框架边界关键词大小写敏感：
UNBOUNDED PRECEDING不能写成unbounded preceding，MySQL 8.0 会报语法错误
OVER 子句里 PARTITION BY 和 ORDER BY 的组合粒度——它直接决定“窗口”的切分逻辑。错一分，排名就乱，累计就串，LAG 就取错行。这不是语法问题，是业务语义映射问题。 
