LAG取上一行、LEAD取下一行，必须配ORDER BY定义行序，否则结果不可靠；不加PARTITION BY则全表视为一组，加了才按业务分组。
直接说结论：用 LAG() 取上一行，LEAD() 取下一行，但必须配 ORDER BY，否则结果不可靠；不加 PARTITION BY 就是全表当一个组算，加了才按业务逻辑分组。
为什么 LAG/LEAD 会返回 NULL 或错乱值
最常见原因是漏写 ORDER BY —— 窗口函数依赖明确的行序，“上一行”“下一行”没顺序就无从定义。MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都强制要求 ORDER BY 子句出现在 OVER() 中，否则报错；某些旧版 MySQL（如 5.7）虽不报错，但结果随机，极易出 bug。
另一个高频坑是误以为 PARTITION BY 可选就省略，结果跨产品、跨用户、跨日期混算。比如查每个用户的登录间隔，却没写 PARTITION BY user_id，那第二个人的第一条记录就会去拿第一个人的最后一条时间，完全失真。
-
LAG(amount)不带ORDER BY→ 返回任意行的amount，不可预测 - 有
ORDER BY date但没PARTITION BY user_id→ 所有用户时间混排，A 用户的“前一天”可能是 B 用户的数据 - 排序字段含重复值（如多个同秒订单）且未加唯一键辅助 → 数据库可能任意打乱相同
date的行序，导致LAG结果不稳定
LAG 和 LEAD 的参数怎么填才不踩默认值陷阱
LAG(column, offset, default) 三个参数里，offset 和 default 都是可选，但省略它们常引发隐性问题。
比如只写 LAG(amount)，等价于 LAG(amount, 1, NULL)。首行必然返回 NULL，如果后续做除法或累加，NULL 会污染整条计算链（如 amount / LAG(amount) 得到 NULL）。这时候显式给 default 更安全：
- 环比计算常用
LAG(amount, 1, 0)，让首日“前一日销售额”为 0，避免空值中断 - 趋势判断可用
LEAD(status, 1, 'unknown')，比NULL更易读、更易在 WHERE 中过滤 -
offset不一定总用 1：想看“上上周销量”，就写LAG(amount, 7)（前提是按天排序），但注意偏移超出范围时仍走default分支
真实业务场景中怎么组织 PARTITION BY + ORDER BY
分组和排序不是技术配置，而是业务语义的映射。关键看“谁跟谁比”：
- 查每个产品的日销环比 →
PARTITION BY product_id ORDER BY sale_date - 查每位员工在部门内的绩效排名及与上一名的分差 →
PARTITION BY dept_id ORDER BY score DESC，再套LAG(score) - 查用户每次下单距上次的天数 →
PARTITION BY user_id ORDER BY order_time，然后order_time - LAG(order_time)
特别注意：如果排序字段本身有业务含义（如 created_at），别用 id 替代——id 递增不等于时间递增，尤其在分库分表或批量导入场景下。
性能和兼容性要盯住这三点
LAG/LEAD 本身不慢，慢的是没索引的 ORDER BY 字段。执行计划里若出现 Using filesort，说明数据库正在内存或磁盘排序，大数据量时延迟明显。
- 确保
ORDER BY字段（如sale_date）上有索引，复合索引优先考虑(product_id, sale_date)这类组合 - SQL Server 2012+、MySQL 8.0+、PostgreSQL 8.4+ 原生支持；老版本 MySQL（5.7 及以前）不支持，只能用自连接模拟，性能差、SQL 膨胀
- 某些 OLAP 引擎（如 Doris、StarRocks）支持，但 Hive 3.1 之前仅部分支持，
default参数可能被忽略
真正容易被忽略的，是 ORDER BY 字段的**确定性**——哪怕加了索引，如果排序依据是浮点时间戳或未去重的业务字段，同一查询多次执行都可能拿到不同“上一行”，这种非幂等性在线上分析中很难排查。
