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子句中亲手定义的逻辑顺序所创造的。定义权在你手上，责任也在你肩上。
