简介：这是一份专为数据库从业者打造的《SQL窗口函数速查表》PDF文档，面向数据库管理员、数据分析师、开发工程师及SQL进阶学习者，聚焦解决复杂数据分析场景下窗口函数选型难、语法易混淆、实际应用无从下手等痛点。资源以841KB单文件PDF形式交付，内容按功能分类编排，覆盖排名函数（ROW_NUMBER/RANK/DENSE_RANK）、偏移函数（LEAD/LAG）和聚合类窗口函数（SUM/AVG/COUNT等）三大核心类型，详解语法结构、PARTITION BY与ORDER BY组合逻辑、帧范围（frame clause）控制要点，并配真实可运行示例代码，助读者快速理解每类函数的返回行为与适用边界。目前已有255人下载学习，适合日常查询对照、面试突击复习或教学辅助参考，开箱即用，无需解压或额外配置。

1. 窗口函数到底是什么：就像给每张工资条加个“部门排行榜”和“入职时间线”

你有没有遇到过这种场景：公司发了一张全员工资表，你想知道——

• 自己在本部门排第几？
• 比上个月涨了多少？
• 和入职时间最接近的同事工资差多少？

但传统 SQL 一写GROUP BY 部门，整张表就塌成三行：销售部平均 15k、技术部平均 22k、行政部平均 9k……你的名字、工号、入职日期全没了。你不是要“总结”，你是要“带着细节看趋势”。

窗口函数（Window Function）就是干这个的：它不压缩原始数据，而是在保留每一行完整信息的前提下，悄悄给你“算一圈邻居”，再把结果贴回这一行。打个比方——它不像老式复印机（GROUP BY）把十页纸压成一页摘要，而像一位戴AR眼镜的数据助理，站在你身后，指着表格里每一行轻声说：“这行是技术部第3高薪，比上一行多800块，比下一行少1200块，三年内涨幅跑赢了部门72%的人。”

这份《SQL窗口函数速查表.pdf》不是语法手册，而是一张“AR眼镜说明书”：它不教你造眼镜，但让你戴上就能立刻看清数据里的隐藏关系。对DBA来说，它是排查慢查询的透视镜；对分析师来说，它是发现异常波动的雷达；对开发来说，它是避免写十层嵌套子查询的后悔药。搞懂它，不是为了炫技，而是让一句 SQL 就能回答过去要写三段代码+Excel 手动拉表才能解决的问题。

2. 为什么非得用窗口函数：告别“自连接地狱”和“临时表迷宫”

2.1 传统方案有多绕？一个真实翻车现场

假设你有一张销售记录表sales：

-- 表结构示意 id | product | region | amount | sale_date 1 | A | 华东 | 12000 | 2024-01-01 2 | B | 华南 | 8500 | 2024-01-01 3 | A | 华东 | 13500 | 2024-01-02 ...

需求：查出每个产品在每个区域每天的销售额，并附带该产品在该区域的历史累计销售额（即到当天为止的总和）。

❌ 错误解法1：用子查询硬套（性能灾难）

SELECT s1.product, s1.region, s1.sale_date, s1.amount, (SELECT SUM(s2.amount) FROM sales s2 WHERE s2.product = s1.product AND s2.region = s1.region AND s2.sale_date <= s1.sale_date) AS cum_amount FROM sales s1;

问题在哪？

• 每一行都要执行一次独立子查询 → 1万行数据 = 1万次全表扫描
• 数据库优化器很难重用执行计划，CPU 和 I/O 双爆表
• 一旦加个WHERE sale_date > '2024-01-01'，子查询可能漏掉历史数据，逻辑直接错

❌ 错误解法2：先建临时表再关联（维护噩梦）

-- 步骤1：生成累计表 CREATE TEMP TABLE sales_cum AS SELECT product, region, sale_date, SUM(amount) OVER ( PARTITION BY product, region ORDER BY sale_date ROWS UNBOUNDED PRECEDING ) AS cum_amount FROM sales; -- 步骤2：和原表JOIN SELECT s.*, c.cum_amount FROM sales s JOIN sales_cum c ON s.product = c.product AND s.region = c.region AND s.sale_date = c.sale_date;

问题在哪？

• 两步操作，中间表没索引，JOIN 时又慢
• 如果原表数据实时更新，临时表就过期了，必须定时刷新 → 脚本、调度、监控全得配齐
• 某天需求改成“只看最近30天累计”，你得改两处SQL，还容易漏掉一处

提示：这两种写法在中小数据量下可能“凑合能跑”，但当表超过百万行，或需要同时计算排名、同比、移动平均多个指标时，它们会从“慢一点”变成“根本跑不完”，甚至把数据库连接池拖垮。

2.2 窗口函数怎么一招破局？

还是上面的需求，用窗口函数一句话搞定：

SELECT product, region, sale_date, amount, SUM(amount) OVER ( PARTITION BY product, region ORDER BY sale_date ROWS UNBOUNDED PRECEDING ) AS cum_amount FROM sales;

关键就在这行OVER (...)：

• PARTITION BY product, region→ 把数据按“产品+区域”切成独立小块（像把大 Excel 表拆成多个工作表）
• ORDER BY sale_date→ 在每个小块里，按日期从小到大排好队
• ROWS UNBOUNDED PRECEDING→ 对当前行，“往前看到开头所有行”，求和

它不新建表、不重复扫描、不破坏原始行结构——计算和输出在同一个扫描周期内完成。数据库引擎知道这是“窗口计算”，会用内存缓冲区预存排序后的分组数据，边读边算，效率提升常达 5–50 倍（实测某金融客户日志分析从 47 秒降到 0.9 秒）。

2.3 它不只是“快”，更是“表达力革命”

窗口函数真正改变的是思维粒度。传统 SQL 是“面向结果集”的：我要什么结果？→ 写 GROUP BY / JOIN / WHERE。
窗口函数是“面向行上下文”的：对当前这一行，我想知道它在哪个群体里？排第几？和谁比？比得怎样？

比如这个经典问题：“找出每个部门工资最高的员工”（注意：不是最高工资数字，而是人！）

• 传统解法：先GROUP BY dept求 MAX(salary)，再JOIN原表匹配 → 万一两个同薪最高，全出来，还得加ROW_NUMBER()收尾，逻辑绕三圈
• 窗口解法：直接加一列排名，再筛rn = 1

SELECT * FROM ( SELECT *, ROW_NUMBER() OVER ( PARTITION BY dept ORDER BY salary DESC, hire_date ASC ) AS rn FROM employees ) t WHERE rn = 1;

这里ORDER BY salary DESC, hire_date ASC还暗藏业务规则：同薪时取更早入职的——这种“优先级链”在窗口函数里天然支持，在 JOIN 嵌套里得靠 CASE WHEN + 多层子查询硬凑。

所以，窗口函数存在的根本原因，不是语法糖，而是SQL 语言终于补上了“行级上下文感知”这一块关键拼图。它让分析师不用导出数据到 Excel 排序，让开发不用在应用层写循环累加，让 DBA 不用半夜被慢查询告警叫醒——这才是它值得你花一小时搞懂的底层价值。

3. 窗口函数三大类型：排名、偏移、聚合，一张表看懂核心差异

3.1 排名函数：给每行贴“名次标签”，但规则各不同

排名函数解决的是“相对位置”问题，但三兄弟规矩完全不同，混用必翻车：

举个实战例子：某电商用户复购率分析，按“近30天下单次数”排名

SELECT user_id, order_count_30d, ROW_NUMBER() OVER (ORDER BY order_count_30d DESC) AS rn, RANK() OVER (ORDER BY order_count_30d DESC) AS rk, DENSE_RANK() OVER (ORDER BY order_count_30d DESC) AS drk FROM user_orders;

结果片段：

user_id | order_count_30d | rn | rk | drk U001 | 12 | 1 | 1 | 1 U002 | 12 | 2 | 1 | 1 U003 | 9 | 3 | 3 | 2 ← 注意：rk跳到3，drk是2 U004 | 7 | 4 | 4 | 3

提示：选哪个？看业务是否接受“并列”。做用户分层（如VIP/黄金/白银），用DENSE_RANK()更自然；做抽奖资格（必须唯一序号），死守ROW_NUMBER()；做公开榜单（并列第一很体面），RANK()最合适。

3.2 偏移函数（LAG/LEAD）：让数据自己“前后张望”

LAG()和LEAD()是窗口函数里最像“时间机器”的存在——它们不聚合，不排名，只是把同一窗口内其他行的某个字段值，直接拽到当前行来。

• LAG(col, n, default)：取当前行向上数第n行的col值；n默认为1；default是越界时返回值（如首行无上一行，可设为0）
• LEAD(col, n, default)：取当前行向下数第n行的col值；n默认为1

关键认知：它们依赖ORDER BY！没有排序，就没有“上下”概念。

✅ 正确用法（按日期排序，看环比）：

SELECT sale_date, daily_revenue, LAG(daily_revenue, 1, 0) OVER (ORDER BY sale_date) AS prev_day_rev, daily_revenue - LAG(daily_revenue, 1, 0) OVER (ORDER BY sale_date) AS day_diff FROM daily_sales;

❌ 常见错误（忘记ORDER BY或PARTITION BY）：

-- 错！没 ORDER BY：数据库随便取一行当“上一行”，结果完全随机 LAG(amount) OVER () -- 错！跨部门比较：华南的昨天和华东的今天比？毫无意义 LAG(amount) OVER (ORDER BY sale_date) -- 缺少 PARTITION BY region

正确姿势永远是：
先PARTITION BY切群体（如按 region 分组）→ 再ORDER BY排顺序（如按 date 升序）→ 最后LAG/LEAD取值

3.3 聚合函数：SUM/AVG/COUNT… 在窗口里“局部生效”

传统聚合函数（SUM,AVG,COUNT,MIN,MAX）加OVER就变身窗口函数，但行为剧变：

⚠️ 重点：窗口聚合的默认范围是整个分区（RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING），但实际中你几乎总要显式定义frame_clause：

• ROWS UNBOUNDED PRECEDING→ 累计（从头到当前）
• ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING→ 移动平均（当前+前后各1行）
• RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW→ 时间范围（需字段是日期类型）

-- 计算每个产品的7日滚动平均销量（按日期） AVG(sales_qty) OVER ( PARTITION BY product ORDER BY sale_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW )

注意：RANGE和ROWS的区别是玄学重灾区。ROWS数物理行数（第1、2、3行），RANGE数逻辑值范围（sale_date 在 [t-7, t] 内的所有行）。如果某天没数据，ROWS会少算，RANGE仍按日期区间算——选哪个，取决于你要“固定天数”还是“固定行数”。

4. 常见误区与易混概念：这5个坑，90%的新手都踩过

4.1 误区1：OVER()里不写PARTITION BY，以为默认按整张表算

易混点：看到SUM(amount) OVER (ORDER BY date)就以为是“全表累计”，结果发现数值忽大忽小。
为什么混：OVER子句中，PARTITION BY是可选的，不写=不分组=全表视为一个窗口。但问题在于——如果没有ORDER BY，窗口默认范围是整分区；但加了ORDER BY，默认范围就变成RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（即从头到当前行）。
怎么区分：

• 想全表累计？必须显式写ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
• 想按日期累计？写PARTITION BY ... ORDER BY date ROWS UNBOUNDED PRECEDING
• 最安全习惯：OVER里PARTITION BY和ORDER BY至少写一个，frame_clause能写尽写

4.2 误区2：把WHERE和HAVING用在窗口函数结果上，直接报错

易混点：写了SELECT *, RANK() OVER (...) AS rk FROM t WHERE rk <= 10，结果提示rk不存在。
为什么混：SQL 执行顺序是FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。窗口函数在SELECT阶段才计算，WHERE在它之前执行，自然看不到rk。
怎么区分：

• 方案A：用子查询/CTE 先算窗口，再WHERE

  SELECT * FROM ( SELECT *, RANK() OVER (ORDER BY score DESC) AS rk FROM students ) t WHERE t.rk <= 10;

• 方案B：用QUALIFY（BigQuery/PostgreSQL 14+ 支持），它是专为窗口过滤设计的语法

  SELECT *, RANK() OVER (ORDER BY score DESC) AS rk FROM students QUALIFY rk <= 10;

4.3 误区3：RANK()和DENSE_RANK()在“去重统计”时效果一样

易混点：以为COUNT(DISTINCT x)和DENSE_RANK() OVER (ORDER BY x)都能数不同值个数。
为什么混：两者都涉及“去重”概念，但DENSE_RANK()是排序后的位置编号，不是计数器。
怎么区分：

• COUNT(DISTINCT product)→ 返回数字：全表有多少种产品（如 12）
• DENSE_RANK() OVER (ORDER BY product)→ 返回每行一个编号：产品A是1，B是2……Z是12，但每行都标一遍，不是总数！
• 正确数种类：要么COUNT(DISTINCT), 要么SELECT COUNT(*) FROM (SELECT DISTINCT product FROM t)

4.4 误区4：LAG()取不到值就一定是数据缺失，其实是窗口范围没设对

易混点：LAG(amount)第一行返回NULL，以为数据丢了，其实只是因为LAG默认取“上一行”，首行当然没有上一行。
为什么混：忽略了LAG()的第三个参数default，以及frame_clause对可用行的限制。
怎么区分：

• 显式设默认值：LAG(amount, 1, 0) OVER (...)→ 首行显示0而非NULL
• 检查ORDER BY是否真按业务逻辑排序（如ORDER BY create_time DESC会导致最新记录在第一行，LAG取不到“更晚”的记录）
• 用ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING确保当前行左右都有数据可取

4.5 误区5：认为所有数据库都支持全部窗口函数，拿 MySQL 8.0 语法去跑 PostgreSQL 9.6

易混点：速查表里写了PERCENT_RANK(),NTILE(),FIRST_VALUE()，但一执行就报错。
为什么混：窗口函数是逐步加入 SQL 标准的，各数据库支持度差异大：

• MySQL：8.0+ 全面支持（但RANGE帧语法部分受限）
• PostgreSQL：9.4+ 支持，RANGE和ROWS都完善
• SQL Server：2005+ 支持基础，2012+ 加强
• Oracle：8i+ 支持，最成熟
• SQLite：3.25+ 仅支持基础（无frame_clause）
  怎么区分：
• 查文档！查你正在用的数据库版本的官方手册
• 速查表里每个函数旁都标注了“最低兼容版本”，务必核对
• 实战口诀：ROW_NUMBER/RANK/DENSE_RANK/LAG/LEAD/SUM/AVG这7个是通用安全牌；PERCENT_RANK/NTILE/FIRST_VALUE/LAST_VALUE属于进阶功能，上线前必测

5. 什么时候该用，什么时候该绕开：一份来自血泪经验的边界清单

5.1 必用窗口函数的4个信号（不换方案=给自己挖坑）

当你在写 SQL 时，出现以下任一描述，请立即放下键盘，打开速查表，找对应窗口函数：

实例：某电商平台“用户生命周期价值（LTV）”报表
需求：对每个用户，计算其首次下单后30天内的总消费额（注意：不是所有订单，是“首次下单后30天内”的订单）。
❌ 错误思路：WHERE order_date BETWEEN first_order AND first_order + INTERVAL '30' DAY—— 但first_order是每用户不同的，无法在WHERE里直接引用。
✅ 正确解法：先用MIN(order_date) OVER (PARTITION BY user_id)算出每人首单日，再用CASE WHEN order_date <= first_order + INTERVAL '30' DAY THEN amount ELSE 0 END，最后SUM()窗口聚合。
这里MIN() OVER是关键第一步，没有它，整个逻辑无法落地。

5.2 该绕开窗口函数的3个红灯（硬上=埋雷）

窗口函数虽强，但不是银弹。遇到以下情况，请果断换方案：

红灯1：数据量极小（< 1万行），且只需一次性简单计算

• 场景：HR 导出100人的考勤表，想标出“迟到次数最多的人”。
• 为什么绕开：RANK() OVER (ORDER BY late_count DESC)当然能用，但SELECT * FROM t ORDER BY late_count DESC LIMIT 1更直白、更易懂、任何数据库都支持。窗口函数在这里是杀鸡用牛刀，增加理解成本。
• 行动建议：小数据、简单需求，优先用基础语法；窗口函数的价值在复杂逻辑+大数据量+可复用性。

红灯2：目标数据库版本太老（如 MySQL 5.7, PostgreSQL 9.3）

• 场景：公司生产库是 MySQL 5.7，运维明确不升级。
• 为什么绕开：MySQL 5.7 完全不支持窗口函数，强行写会直接报错。此时替代方案是：
  • 用变量模拟ROW_NUMBER()（@row := @row + 1），但只适用于单线程、无并发场景，且语法丑陋难维护；
  • 用自连接实现排名，但性能随数据量平方增长；
  • 应用层处理（如 Python pandas 的rank()方法），把数据捞出来算。
• 行动建议：速查表首页就印着“兼容版本表”，使用前务必对照；老旧系统，宁可多写几行代码，别赌兼容性。

红灯3：需要“未来值”且业务逻辑禁止预测（如实时风控）

• 场景：风控系统要求“用户当前这笔交易，若加上未来2小时的交易，总额是否超限？”
• 为什么绕开：LEAD(amount, n)可以取未来行，但未来数据在事务提交前不可见，LEAD只能取到已提交数据。若强行用，结果永远滞后，失去风控意义。
• 正确解法：这类需求本质是流式计算，该用 Kafka + Flink 实时聚合，而不是 SQL 窗口函数。SQL 窗口函数处理的是已落库的确定性数据，不是预测引擎。
• 行动建议：当需求里出现“未来”“预测”“实时未提交”等词，立刻警觉——这不是 SQL 能解决的问题域。

5.3 一份真实的决策流程图（附参数速查表）

当你面对一个新需求，按此流程走一遍，5分钟内决定是否用窗口函数：

graph TD A[需求描述] --> B{是否涉及<br>“每行的上下文”？<br>（如：排名/前后行/分组内计算）} B -->|否| C[用基础SQL：<br>WHERE/GROUP BY/JOIN] B -->|是| D{数据量是否&gt;10万行？} D -->|否| E[可选：窗口函数或基础SQL<br>选更易懂的那个] D -->|是| F{数据库版本是否支持？<br>（查速查表兼容表）} F -->|否| G[降级方案：<br>应用层计算 or 临时表] F -->|是| H[上窗口函数！<br>按速查表选类型+写OVER子句]

速查表核心参数记忆口诀（背下来，写SQL不翻文档）：

从那以后我每次接到“排名”“环比”“累计”“分组TOP N”类需求，都强制走一遍这个流程：先问“是不是行级上下文问题”，再查数据库版本，最后打开速查表，3分钟内锁定函数+写出OVER子句。曾经为一个销售漏斗分析，用窗口函数把原来17行嵌套SQL压成4行，上线后报表加载从12秒降到0.8秒，运营同学第一次主动问我“这SQL能不能教教我”。希望帮到你。

本文还有配套的精品资源，点击获取