SQL窗口函数实战：避开那些“坑你没商量”的跨行比较陷阱

说到数据分析，跨行比较是个绕不开的活儿。比如，想知道用户这次消费比上次多了多少，或者找出每个部门业绩最好的那一位。这时候，窗口函数（Window Function）就是你的神兵利器。不过，工具虽好，用不对地方，分分钟掉坑里。今天咱们就来聊聊几个最常见的“坑点”，以及怎么稳稳地绕过去。

怎么用 LAG() 和 LEAD() 精准抓取组内“邻居”数据

想比较同一组内的相邻行，思路其实很清晰：先分组，再排序，最后“回头看”或者“向前看”。LAG() 和 LEAD() 干的就是这个。但关键就在于，必须得用 OVER (PARTITION BY ... ORDER BY ...) 这个标准句式把它们框住，才能确保操作只在组内进行。

新手常犯两个错误：一是只写了 ORDER BY 却漏了 PARTITION BY，结果把整个表当成一个大组，数据全乱套了；二是 ORDER BY 的字段有重复值（比如两条记录时间戳相同），却没加上一个具有唯一性的字段（如主键ID）来辅助排序，导致窗口行为飘忽不定，每次查询结果都可能不一样。

• 分组是前提：PARTITION BY 必须显式指定，想清楚按什么分组（用户、部门等），否则就是全局比较。
• 排序要唯一：ORDER BY 的字段组合最好能唯一确定行序。在 MySQL 8.0+ 和 PostgreSQL 中，如果排序不唯一，函数返回值是非确定性的；PostgreSQL 甚至可能直接报错 window function requires a valid ordering。
• 参数有讲究：偏移量默认是1（看紧邻的前后行），但可以通过第二个参数调整，比如 LAG(sales, 2) 就能取前两行的数据。第三个参数是默认值，当没有前一行或后一行时（比如组内第一行用 LAG），可以用它来填充，避免出现恼人的 NULL，例如 LAG(amount, 1, 0)。

来看个具体例子：计算每个用户当前订单金额与上一笔订单的差值。

SELECT user_id, order_time, amount,
       amount - LAG(amount, 1, 0) OVER (
         PARTITION BY user_id ORDER BY order_time, order_id
       ) AS diff_from_prev
FROM orders;

这里，我们按 user_id 分区，确保每个用户独立计算。按 order_time 和 order_id 排序，保证了即使下单时间相同，也能通过ID确定唯一顺序。LAG(amount, 1, 0) 表示取上一行的金额，如果没有（即该用户第一笔订单），则按0处理。

FIRST_VALUE() 和 LAST_VALUE()：为什么结果总“不对劲”？

这两个函数名字起得直白，但行为却有点“狡猾”。默认情况下，它们的窗口帧（Window Frame）是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。翻译过来就是“从分区的第一行，到当前行”。

这下问题就来了：对于 LAST_VALUE(x)，它在每一行返回的，并不是整个分区的最后一个值，而是“从分区开头到当前行”这个范围内的最后一个值。所以，你很可能在结果集中间就看到一个“假”的末尾值。

想要真正拿到整个组内的第一个或最后一个值，必须显式地重新定义窗口帧：

• FIRST_VALUE(x) OVER (PARTITION BY g ORDER BY t ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)
• LAST_VALUE(x) OVER (PARTITION BY g ORDER BY t ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)

注意这里的 UNBOUNDED FOLLOWING，它把窗口扩展到了分区的最后一行。另外，不同数据库还有细微差别：PostgreSQL 要求必须有 ORDER BY 才能使用 ROWS BETWEEN ... 子句；而 SQL Server 允许在没有 ORDER BY 的情况下使用，但语义会有所不同。至于 MySQL 8.0+，虽然支持，但如果排序字段包含 NULL 值，LAST_VALUE 返回的可能是 NULL —— 这并非 bug，而是按照排序规则，NULL 被排在了最后。

报错“Window function is not allowed in WHERE/HA VING”？这才是根本原因

当你试图把 LAG() 或 ROW_NUMBER() 直接塞进 WHERE 或 HA VING 子句时，数据库会毫不客气地抛出这个错误。原因在于 SQL 的执行顺序：WHERE → GROUP BY → HA VING → SELECT → 窗口函数 → ORDER BY。

看到了吗？窗口函数的计算发生在 SELECT 阶段，远在 WHERE 和 HA VING 执行之后。在过滤数据的时候，窗口函数的结果根本还没算出来呢，数据库自然找不到它。

正确的破解方法只有两种：

• 使用子查询或CTE（公用表表达式）：先把带有窗口函数的结果集算出来，包装成一个派生表，然后在外层进行过滤。

  SELECT *
  FROM (
    SELECT *,
           LAG(amount) OVER (PARTITION BY user_id ORDER BY time) AS prev_amount
    FROM transactions
  ) AS subquery
  WHERE prev_amount > 100;

• 改用聚合函数+自连接：这种方法仅适用于非常简单的场景，而且性能往往更差，对于“取上一行”这种典型的窗口函数逻辑，表达起来会非常笨拙。

所以，别再尝试在 HA VING 里套窗口函数，也别指望 WHERE ROW_NUMBER() = 1 能生效了。执行顺序的铁律，是绕不过去的。

MySQL 5.7 的“曲线救国”方案，真的靠谱吗？

很遗憾，MySQL 5.7 及更早版本确实不支持原生的窗口函数。网上流传着用用户变量（如 @prev := @curr）来模拟的方法，看起来似乎能行，但在生产环境尤其是高并发场景下，这堪称一个“定时冲击波”。

MySQL 官方文档明确警告：用户变量的赋值顺序得不到保证，特别是在与 ORDER BY 子句混合使用时，查询结果可能是随机的。依赖这种不确定行为，无异于在刀尖上跳舞。

如果暂时无法升级到 MySQL 8.0 或更高版本，务实的选择并不多：

• 应用层处理：把数据按组取回应用内存，在代码里进行遍历和比较。这只适合数据量小、逻辑不复杂的场景。
• 复杂的自连接：通过 LEFT JOIN 自己，并利用 order_col < ... 和子查询 LIMIT 来模拟“上一行”。这种写法不仅复杂，性能也会随着数据量增长而急剧下降，且可读性极差。
• 降级使用 GROUP_CONCAT：用 GROUP_CONCAT(... ORDER BY ...) 把组内数据拼成一个字符串，再在应用层或通过字符串函数解析。这仅限于比较简单的数值，并且受制于 group_concat_max_len 的长度限制，算是一种“奇技淫巧”。

真正棘手的是那些需要稳定排序、处理重复值、还要分页的复杂场景。到了这一步，变量模拟和自连接都会捉襟见肘。可以说，没有优雅的解决方案，升级数据库版本才是根本出路。