LAG函数查不到上一条订单，是因为它只按ORDER BY返回排序后的前一行，而非业务意义上的“上一条”；必须用PARTITION BY按用户分组、ORDER BY按确定时间排序，并用COALESCE或默认值处理首行NULL。
LAG函数查不到上一条订单？先确认排序逻辑
窗口函数LAG()本身不保证“上一条订单”这个业务语义，它只按ORDER BY子句返回物理排序后的前一行。如果你的订单表没显式按时间或单号排序，LAG(order_amount)可能拉到任意一条——比如按主键ID升序排，但下单时间却是乱的。
实操建议：
- 必须在
OVER()里写明确定的业务排序，例如ORDER BY order_time ASC或ORDER BY order_no ASC - 避免用
ORDER BY id替代业务时间，除非ID严格递增且与下单顺序一致 - 如果有并列时间（如毫秒级相同），加二级排序防结果不稳定，例如
ORDER BY order_time, order_id
LAG取值为空？处理NULL的三种常见方式
首条记录没有“上一条”，LAG()默认返回NULL。直接参与计算（如做差值）会导致整行结果为NULL，这是最常被忽略的坑。
根据场景选处理方式：
- 想保留原始
NULL：什么都不加，LAG(amount) - 想填默认值（如0）：写成
LAG(amount, 1, 0)，第三个参数是默认值 - 想用本行值填充（即“向前补位”）：用
COALESCE(LAG(amount), amount)
注意：LAG(amount, 2)表示跳过1行取前第2条，不是取“上上条订单”，而是按排序位置偏移——这点容易误解。
跨用户查上一条订单？PARTITION BY不能漏
如果订单表含多个用户（user_id），直接LAG(amount) OVER (ORDER BY order_time)会把所有用户混在一起排序，张三的订单可能拉到李四的上一笔。
正确做法是按用户分组后再取上一条：
LAG(amount) OVER ( PARTITION BY user_id ORDER BY order_time )
关键点：
-
PARTITION BY必须放在ORDER BY之前，语法顺序不可颠倒 - 分区字段要和业务粒度一致——按
user_id分就是每个用户独立看历史，按product_id分就是每商品看销售序列 - 如果忘了
PARTITION BY，结果看似正常，但数据逻辑全错，且很难通过肉眼发现
性能卡在LAG？警惕ORDER BY字段没索引
LAG()执行依赖排序，当订单表超百万行且ORDER BY字段无索引时，窗口函数会触发全局排序，拖慢整个查询。
优化方向：
- 确保
ORDER BY用到的字段（如order_time、user_id）有联合索引，例如(user_id, order_time) - 避免在
LAG()中用表达式排序，如ORDER BY DATE(order_time)——这会让索引失效 - MySQL 8.0+ 和 PostgreSQL 支持窗口函数下推优化，但前提仍是基础排序字段可走索引
真正难的不是写对LAG()语法，而是想清楚“上一条”到底属于谁、按什么序、空值怎么算——这些业务定义一旦模糊，代码越“正确”，结果越危险。
