窗口函数可同时保留明细与汇总，如avg(salary) over (partition by department)一行返回每人业绩及部门均值，避免子查询；必须显式指定partition by分组，order by保障排序稳定，窗口帧默认为全分区或到当前行。
报表里要同时看明细和汇总，直接用 AVG() 或 SUM() 加 OVER()
别再写子查询或应用层计算了。窗口函数最实用的场景，就是保留每条订单、每个员工、每门课程的原始记录，同时附带分组统计值。比如查销售员业绩时，既要看到张三单笔 8000 元，又要立刻知道他所在部门平均是 6500 元——AVG(salary) OVER (PARTITION BY department) 一行就搞定。
注意：PARTITION BY 必须明确指定分组字段，否则默认对全表计算；如果漏掉 ORDER BY，像 ROW_NUMBER() 这类函数结果会不稳定（MySQL 不保证无序时的行顺序）。
-
AVG()、SUM()、COUNT()等聚合函数加OVER()后，语义变成“本窗口内聚合”，不是全局聚合 - 没写
PARTITION BY就等于整个结果集是一个窗口，容易误算成全公司均值而非部门均值 - 聚合类窗口函数默认窗口帧是
RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，即整个分区；如需累计效果，必须显式加ORDER BY和ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
排名需求别硬套 ROW_NUMBER()，先想清楚要不要跳号
报表里“Top 10”“前 3 名”这种表述，背后对应的是不同排名逻辑。ROW_NUMBER() 强制连续编号，哪怕分数相同也给不同名次；RANK() 相同值同名次但跳号（95、95、88 → 1、1、3）；DENSE_RANK() 相同值同名次且不跳号（→ 1、1、2）。选错函数，报表数字就会被业务方质疑。
典型陷阱：用 ROW_NUMBER() 做学生成绩排名，结果两个满分学生排第 1 和第 2，家长马上来问“为什么都是 100 分却差一名？”
- 竞赛/榜单类报表（强调名次唯一性）→ 用
ROW_NUMBER() - 成绩/绩效分档（相同得分应同档）→ 优先
RANK()或DENSE_RANK() -
NTILE(4)适合做四分位分析，但数据量少于 4 行时会出NULL，得提前COUNT(*)校验
环比、同比、移动平均这些时间序列指标，靠 LAG() 和 LEAD()
报表常要“比上月增长 XX%”“较去年同期变化”，传统写法得自连接或关联子查询，性能差还易出错。LAG(amount, 1) OVER (PARTITION BY product_id ORDER BY sale_date) 直接取前一行销售额，配合简单运算就能算出环比。
关键点：必须确保 ORDER BY 字段能唯一确定时间顺序，否则 LAG() 可能跨月取错数据。日期字段如果有重复（比如同天多笔订单），建议加上二级排序，例如 ORDER BY sale_date, id。
-
LAG(col, n)取往前第 n 行，LEAD(col, n)取往后第 n 行 - 没数据时默认返回
NULL，可加第三个参数设默认值，如LAG(amount, 1, 0) - 窗口帧不显式声明时，默认是
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，对LAG/LEAD没影响，但对累计类函数很关键
复杂报表别堆一个 SQL，用 WINDOW 子句复用定义
当一条报表 SQL 要同时算排名、累计、环比、部门均值，OVER() 重复写五六遍不仅难读，改起来也容易漏。MySQL 8.0 支持 WINDOW 子句提前定义窗口，后面直接引用。
比如：WINDOW w AS (PARTITION BY class ORDER BY score DESC)，之后所有 ROW_NUMBER() OVER w、RANK() OVER w 都复用这个逻辑，改排序或分组只动一处。
-
WINDOW定义放在FROM之后、WHERE之前，作用域覆盖整个查询 - 不能在子查询里定义
WINDOW，外层无法继承；嵌套查询需各自定义 - 别为了“看起来简洁”强行复用窗口——如果某列需要按时间排序，另一列按金额排序，就必须定义两个独立窗口
ORDER BY 时默认只算到当前行，没 ORDER BY 时默认算整个分区。这个细节直接决定累计求和是对的还是错的。
