窗口函数解决GROUP BY无法同时保留明细与聚合值的问题，支持分区计算不减少行数，并需注意PARTITION BY与ORDER BY的语义、排序函数差异及数据库兼容性。
为什么 GROUP BY 不够用，非得上窗口函数？
GROUP BY 一聚合，原始行就没了——你想看每条订单的金额，同时还要知道它所属用户的平均订单额，GROUP BY user_id 直接把订单明细压成一行，没法并存。窗口函数不减少行数，只在逻辑分区里算值，天然适合“既要个体，又要群体”的场景。
- 常见错误现象：
SELECT order_id, amount, AVG(amount) FROM orders GROUP BY order_id报错或结果为单条，因为AVG()和非分组字段混用不合法 - 正确姿势：用
AVG(amount) OVER (PARTITION BY user_id)，user_id是分组依据，但不改变输出行数 - 注意：
PARTITION BY等价于分组，但不等价于GROUP BY；它不强制聚合，也不过滤行
ROW_NUMBER()、RANK()、DENSE_RANK() 怎么选？
排序类窗口函数看着像，行为差很多，尤其涉及并列时：
-
ROW_NUMBER()：纯编号，1,2,3,4… 即使值相同也绝不重复，适合取“第 N 条”（如最新一条记录） -
RANK()：并列则跳号，比如两个并列第1，下一个是第3（1,1,3,4），适合榜单排名 -
DENSE_RANK()：并列不跳号，1,1,2,3… 适合分档（如Top 3档位） - 实操建议：先明确业务是否允许“跳名次”，再选；误用
ROW_NUMBER()做排行榜会悄悄漏掉并列用户
ORDER BY 在窗口定义里写错，结果就全乱了
窗口函数里的 ORDER BY 不是给最终结果排序的，而是决定当前窗口内计算的顺序——这对 LAG()、LEAD()、累计求和等函数至关重要：
- 常见错误：写
SUM(amount) OVER (PARTITION BY user_id ORDER BY create_time)却忘了create_time有重复值，导致累计和不稳定（同一秒多笔订单，顺序未定义） - 解决办法：补一个唯一键兜底，比如
ORDER BY create_time, order_id - 性能提示：带
ORDER BY的窗口函数通常比不带的慢，尤其大数据量；如果只是分组计数，别画蛇添足加ORDER BY
MySQL 8.0+ 和 PostgreSQL 的兼容性坑
窗口函数不是所有版本都支持，而且默认行为有差异：
- MySQL 8.0 才正式支持，5.7 及以前直接报错
ERROR 1064 (42000): You have an error in your SQL syntax - PostgreSQL 默认支持，但
frame_clause（如ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW）在 MySQL 中可省略，在 PG 中有时必须显式写，否则语义不同 - 实操建议：跨数据库迁移前，先查目标环境版本；用
SELECT VERSION()确认；避免依赖隐式帧定义
窗口函数真正的复杂点不在语法，而在“想清楚哪一层该分组、哪一层该排序、哪一层该保留原始粒度”——这三个维度一旦叠在一起，光靠试错很难对齐预期。很多人卡住，其实是没先画出数据流草图：原始表 → 分区 → 排序 → 计算 → 输出。
