LAG函数必须配合ORDER BY才能正确取前一行，否则行序无保证；需按业务需求选择排序字段并处理重复值；注意空值、数据类型及offset/default参数；性能上应合理使用PARTITION BY和索引。
LAG 函数必须配合 ORDER BY 才能正确取“前一行”
不写 ORDER BY 的 LAG() 没有意义——数据库根本不保证行顺序，所谓“前一行”可能是任意一行。很多人写了 LAG(value) 却发现结果乱序或全为 NULL，根本原因就是漏了排序依据。
-
LAG()是窗口函数，只在当前窗口内按指定顺序找上一行，没ORDER BY就没有“上一行”的定义 - 业务上想比“时间上一条”，就得用时间字段排序；想比“ID 递增的上一条”，就得
ORDER BY id - 如果排序字段有重复值（比如多个订单同秒创建），必须加二级排序（如
ORDER BY created_at, id）来保证确定性
对比当前行与前一行：用 LAG 做差值或布尔判断
直接用 LAG() 取出前值，再和当前列做运算或比较，是最常见需求。但要注意空值处理和数据类型对齐。
- 第一次出现的行没有“前一行”，
LAG()默认返回NULL，直接参与减法会把整行结果变NULL，建议用COALESCE(LAG(col), 0)或IS NULL判断 - 字符串列慎用减法，想看是否变化，优先用
col != LAG(col)（注意 NULL 安全比较，可用IS DISTINCT FROM在 PostgreSQL 中，MySQL/SQL Server 需拆开写） - 示例：查每笔订单金额相比上一笔的变化
SELECT amount, LAG(amount) OVER (ORDER BY order_time) AS prev_amount,<br> amount - COALESCE(LAG(amount) OVER (ORDER BY order_time), 0) AS diff<br>FROM orders;
LAG 的 offset 和 default 参数不是可有可无的装饰
LAG(col, offset, default) 三个参数中，offset 控制跳几行（默认 1），default 控制找不到时填什么。忽略它们会导致逻辑错位或意外 NULL。
- 想比“上上行”，必须显式写
LAG(col, 2)，不能靠嵌套调用LAG(LAG(col))（语法错误） -
default填0还是current_value要看业务：累计变动场景常填0，状态继承场景可能填当前值本身 - MySQL 8.0+、PostgreSQL、SQL Server 都支持这三个参数；SQLite 支持但
default为NULL且不可改；旧版 Hive 不支持default，得用COALESCE包一层
性能陷阱：LAG 在大数据量下容易拖慢查询
LAG() 本身不慢，但它的窗口范围（尤其是未加 PARTITION BY 时）会让数据库扫描全部排序后的结果集。线上查千万级日志表时，这很容易触发 OOM 或超时。
- 务必确认是否需要全局排序：如果是按用户分组对比，一定要加
PARTITION BY user_id ORDER BY event_time，否则性能断崖下跌 - 避免在
WHERE条件里依赖LAG()结果（如WHERE amount > LAG(amount)），这会强制先算完整窗口再过滤，应改为子查询或 CTE 先过滤再开窗 - 索引要覆盖
ORDER BY字段，否则排序成本远高于计算成本；复合索引顺序需严格匹配窗口排序顺序
复杂点在于：窗口定义（PARTITION BY + ORDER BY）一旦写错，结果错得毫无征兆，而且很难通过肉眼校验发现。尤其当业务逻辑隐含“每个用户独立序列”却忘了分区时，跨用户混算的差异值会安静地污染所有分析结论。
