MySQL 8.0 中窗口函数必须带 OVER 子句，否则报语法错误；其核心是明确定义数据窗口范围与排序逻辑，支持 PARTITION BY 分区、ORDER BY 排序及帧子句，适用于 TopN、滚动平均、同比环比等场景。
窗口函数在 MySQL 8.0 中必须带 OVER 子句
MySQL 8.0 不支持“裸用”窗口函数（比如直接写 ROW_NUMBER()），否则会报错 ERROR 1064 (42000): You have an error in your SQL syntax。根本原因在于：窗口函数不是聚合函数，它不折叠行，但必须明确指定“数据窗口”的范围和排序逻辑。
实操要点：
-
OVER子句至少要包含ORDER BY（多数场景下），否则像ROW_NUMBER()、RANK()这类函数结果不可预期（MySQL 允许无ORDER BY，但行为等价于随机排序） - 分区用
PARTITION BY，例如按部门统计员工薪资排名：ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) - 省略
PARTITION BY表示全表为一个窗口；省略ORDER BY则多数排名/累计类函数返回结果不稳定 - 帧子句（如
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW）只对SUM()、AVG()等聚合型窗口函数有意义，对LAG()或FIRST_VALUE()无效
报表常用场景：同比环比、滚动平均、TopN 排名
这类查询过去常靠自连接或子查询实现，性能差且难维护。窗口函数能大幅简化逻辑，但要注意语义是否匹配实际业务需求。
典型写法与陷阱：
- 环比（相比上期）：用
LAG(sales, 1) OVER (ORDER BY month)，注意LAG默认返回NULL（首行无前值），需用COALESCE处理，否则sales / LAG(...)会得NULL - 滚动 3 个月平均：
AVG(sales) OVER (ORDER BY month ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)—— 这里2 PRECEDING是关键，不是3 PRECEDING（因为含当前行共 3 行） - 每组 Top3：用
ROW_NUMBER() OVER (PARTITION BY category ORDER BY score DESC)，再在外层WHERE rn ；别用 <code>RANK()，否则并列第 1 名会导致取到 4 行甚至更多 - 累计求和：
SUM(amount) OVER (ORDER BY date ROWS UNBOUNDED PRECEDING)，必须显式写ROWS UNBOUNDED PRECEDING，否则 MySQL 默认是RANGE模式，在日期有重复时可能多算
ORDER BY 在 OVER 和主查询中同时存在时的行为
这是最容易混淆的点：窗口函数里的 ORDER BY 只影响窗口内计算顺序，不决定最终结果集的输出顺序；主查询的 ORDER BY 才控制返回行序。
常见错误现象：
- 写了
ROW_NUMBER() OVER (ORDER BY create_time)，但查出来行序乱 —— 因为没写最外层ORDER BY create_time - 想按分组内时间倒序排号，但又希望最终结果按用户 ID 升序展示，就得写两套
ORDER BY：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC)+ 主查询末尾ORDER BY user_id - 如果主查询有
GROUP BY，而窗口函数里又用了ORDER BY，MySQL 8.0 允许，但逻辑上已脱离分组上下文（窗口计算发生在分组前）
性能与索引配合的关键细节
窗口函数本身不走索引，但 OVER 子句中的 ORDER BY 和 PARTITION BY 字段，强烈建议建联合索引。否则排序开销大，尤其数据量超 10 万行后延迟明显。
优化建议：
- 索引顺序应尽量匹配
PARTITION BY+ORDER BY字段，例如OVER (PARTITION BY region ORDER BY sale_date)对应索引(region, sale_date) - 避免在
OVER中使用函数或表达式排序，如ORDER BY YEAR(create_time)—— 无法利用索引，强制 filesort - 测试发现：对千万级订单表做分月累计，加了
(shop_id, order_time)索引后，执行时间从 8.2s 降到 0.35s -
EXPLAIN中若看到Using temporary; Using filesort，基本说明窗口排序没走索引，得回头检查字段和索引定义
真正麻烦的是 PARTITION BY 字段基数高（比如用户 ID）、又没索引的情况——此时 MySQL 会把整个分区数据拉进内存排序，OOM 风险不小。这种场景得提前评估数据分布，必要时加覆盖索引或拆分查询。
