SQL如何获取上一行数据进行对比_巧用LAG窗口函数解决

SQL窗口函数实战：如何精准获取“上一行”数据并避免常见陷阱

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

在数据分析中，对比当前行与上一行的数据是一个高频需求，比如计算日环比、追踪状态变化或者分析序列差值。要实现这个功能，LAG窗口函数无疑是首选工具。但先别急着写代码，有几个核心要点必须厘清：LAG函数必须配合OVER子句并指定ORDER BY排序逻辑才能正确获取上一行值，否则结果不可控；默认取前1行，支持偏移量和默认值；首行无上一行返回NULL，需用COALESCE或CASE显式处理；MySQL 8.0前不支持，需变量模拟但风险高；排序必须确定，避免因时区、精度或分组顺序导致结果偏差。

LAG函数怎么写才能拿到上一行的值

直接使用LAG()函数看起来简单，但关键在于必须配合OVER子句来明确定义排序逻辑。数据库可不会自动理解你心目中的“上一行”是什么顺序，它只认ORDER BY里白纸黑字写好的规则。

一个最常见的错误就是漏掉ORDER BY。比如写成LAG(amount) OVER ()——这种写法在多数数据库里要么直接报错，要么返回一个不可预测的行，那可不是你想要的“上一行”。

• LAG(column_name)默认就是取前1行，它完全等价于LAG(column_name, 1)。
• 如果需要获取更早的数据，比如上两行，把偏移量改成2就行：LAG(column_name, 2)。
• 第三个参数可以设置默认值，非常实用。例如LAG(amount, 1, 0)，当某一行没有上一行（比如首行）时，它会返回0而不是NULL。
• 最后，敲黑板了：排序字段必须具有确定性。如果只用id排序但存在重复值，结果就可能飘忽不定。更稳妥的做法是使用复合排序，比如ORDER BY created_at, id。

对比当前行和上一行的差值总报NULL怎么办

这个问题困扰过很多人：明明逻辑看起来没错，一计算差值，结果列却满是NULL。其实，这根本不是BUG，而是预期行为。想想看，第一行数据哪来的“上一行”？LAG()函数拿不到值，自然就返回NULL。任何数与NULL做运算，结果还是NULL。

所以，解决思路不是去消灭NULL，而是学会显式地处理它：

• 使用COALESCE(LAG(amount), amount)。这个技巧很巧妙，它把首行“缺失的上一行值”用其自身金额补上，这样计算差值时首行结果就是0。
• 如果业务逻辑需要更清晰的表达，可以用CASE语句：CASE WHEN LAG(amount) IS NULL THEN 0 ELSE amount - LAG(amount) END。
• 特别注意，别试图在WHERE子句里过滤LAG(...) IS NOT NULL——窗口函数不能用在WHERE条件中。它们只能出现在SELECT列表里，或者带聚合函数时的HA VING子句中。

LAG在MySQL 8.0之前根本不能用，有没有替代方案

这是一个很现实的技术版本问题。如果你的数据库是MySQL 5.7或更早的版本，那么很遗憾，直接使用LAG()会收到一个熟悉的报错：ERROR 1064: You ha ve an error in your SQL syntax，因为这些版本根本不支持窗口函数。

这时候，唯一的替代方案就是使用用户变量来模拟行间计算，但这条路布满了陷阱：

• 你必须先用子查询或公共表表达式（CTE）把数据按需要的顺序排好，然后在外部查询里用用户变量（如@prev, @curr）进行逐行计算和赋值。
• 最大的风险在于变量赋值的顺序严重依赖MySQL优化器的执行计划。不同版本、不同数据量下的执行计划稍有变动，结果就可能全乱。
• 对于有并发写入的生产环境，用户变量的状态还可能被其他会话干扰，导致数据错乱。因此，如果业务允许，升级到MySQL 8.0+直接使用原生LAG()函数，是远比变量模拟更可靠的选择。当然，如果用的是PostgreSQL、SQL Server、Oracle或BigQuery等数据库，那就没有这个烦恼了，它们都原生支持。

用LAG计算环比时为什么结果和Excel对不上

辛辛苦苦用SQL算出了环比增长率，一和业务同事的Excel表格核对，发现数字对不上？别慌，这大概率不是谁算错了，而是双方对“上一行”的定义压根不一致。

Excel默认按照你肉眼所见的工作表行序来计算“上一行”。而SQL里的ORDER BY如果没写完整、写明确，数据库可能会按照它内部的索引顺序，甚至是某种任意顺序来返回数据。以下几个细节特别容易踩坑：

• 时间精度问题：时间字段dt如果包含秒级甚至毫秒级精度，但显示时只到“日”，那么同一天内的多条记录排序可能就是未定义的。解决办法是加一个二级排序字段，例如ORDER BY dt, id。
• 业务逻辑混淆：业务上想对比的是“上一日”的数据，但SQL可能取的是原始数据表中的“上一行”。如果一天有多条记录，这俩概念天差地别。正确的做法是先按天进行GROUP BY聚合，再对聚合后的结果使用LAG()。
• 时区陷阱：数据库存储的是UTC时间，应用层展示的是本地时间。如果没转换好，你以为的“同一天”数据，在数据库层面可能已经跨天了。
• 执行顺序：LAG()是依据窗口定义（OVER子句）里的顺序取值的，它和GROUP BY的分组粒度无关。记住一个原则：先GROUP BY聚合，再对聚合结果使用LAG，顺序别搞反。

说到底，最常让人卡住的往往不是语法错误，而是没能意识到：“上一行”这个概念本身并不存在于原始数据中，它完全是由你在ORDER BY子句中亲手定义的逻辑顺序所创造的。定义权在你手上，责任也在你肩上。