mysql 8.0 窗口函数必须严格指定 partition by、order by 和帧子句，缺一不可；漏写 partition by 导致全表计算，漏写 order by 使排名或累计结果不可预测，错用 rows/range 或缺失索引将引发性能与语义双重偏差。
MySQL 8.0 的窗口函数能显著简化多层嵌套的报表统计逻辑，但直接套用 ROW_NUMBER() 或 SUM() OVER 很容易因分区或排序错位导致结果偏差——关键不是“能不能用”，而是“在哪一分区、按什么顺序、对哪一列累积”必须严丝合缝。
为什么 GROUP BY + 子查询在报表里越来越难维护
当需要同时计算“每个部门销售额排名”“累计到当前排名的总销售额”“该部门占比”时，传统写法往往要三层嵌套：最内层聚合，中间层加变量模拟排名，外层再关联算占比。不仅可读性差，而且 ORDER BY 和 GROUP BY 的作用域混乱，一旦加了 LIMIT 或分页就全错。
- 变量方式（
@row := @row + 1）在 MySQL 8.0 中已被明确不推荐，执行计划不稳定，且无法在视图或 CTE 中复用 -
JOIN多次自关联求累计值，数据量稍大（>10 万行）就明显变慢，且难以表达“向前 3 行滚动平均”这类逻辑 - 应用层拼接统计（如先查出明细再用 Python 算排名）会把压力转给业务服务器，丢失数据库端的并行能力和索引下推优势
OVER(PARTITION BY ... ORDER BY ...) 的三个必填要素缺一不可
窗口函数不是加个括号就能跑通——漏写 PARTITION BY 会导致全表排序，漏写 ORDER BY 会让 RANK() 或 AVG() OVER 结果不可预测（MySQL 不保证无序时的默认顺序），而错配字段类型（比如用字符串字段做 ORDER BY）可能让排名跳变。
-
PARTITION BY department_id：定义“在哪个维度内独立计算”，不是过滤条件，也不等价于WHERE；如果漏写，COUNT() OVER()就变成全表计数，而非各部门内计数 -
ORDER BY sale_amount DESC：决定窗口内行的处理顺序，直接影响ROW_NUMBER()编号和SUM() OVER(ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)的累加路径 - 注意 NULL 处理：
ORDER BY sale_amount DESC默认把 NULL 排在最前，若想排最后，需显式写ORDER BY sale_amount DESC NULLS LAST（MySQL 8.0.22+ 支持）
报表常用模式：排名、累计、同比，对应窗口写法差异
同一张销售表，不同统计目标对应完全不同的窗口定义，不能复用同一个 OVER 子句。
- 部门内销售额 Top 3：用
RANK() OVER(PARTITION BY department_id ORDER BY sale_amount DESC)，注意RANK()会并列跳号，DENSE_RANK()并列不跳号，ROW_NUMBER()强制唯一编号 - 滚动 7 天销售额：必须用
SUM(sale_amount) OVER(ORDER BY sale_date RANGE BETWEEN INTERVAL 6 DAY PRECEDING AND CURRENT ROW)，这里RANGE比ROWS更适合日期场景，避免因某天无数据导致断档 - 月度环比（当前月 / 上月）：先用
LAG(sale_amount, 1) OVER(PARTITION BY YEAR(sale_date), MONTH(sale_date) ORDER BY sale_date)拿上月值，再在外部计算比值；注意LAG第二参数是偏移行数，不是偏移月份
性能陷阱：ORDER BY 字段没索引，窗口函数就成全表扫描
窗口函数本身不走索引，但 OVER 子句里的 ORDER BY 字段如果有对应索引，MySQL 才能利用索引有序性避免额外排序。否则即使只查 100 行，也可能触发临时表 + filesort。
- 检查执行计划：重点关注
Extra列是否含Using temporary; Using filesort，出现即代表窗口排序未命中索引 - 复合索引设计优先级：如常用
PARTITION BY dept_id ORDER BY sale_date DESC，则建索引INDEX(dept_id, sale_date)，而非单独为sale_date建索引 - 大数据量慎用
UNBOUNDED FOLLOWING：比如SUM() OVER(... ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING)需从当前行扫到分区末尾，比UNBOUNDED PRECEDING开销更大
真正卡住报表优化的，往往不是不会写 OVER，而是没意识到 PARTITION BY 和业务维度是否对齐、ORDER BY 字段有没有索引、以及 ROWS 和 RANGE 在时间序列里行为完全不同——这些细节错一点，结果就偏一截，性能掉一档。
