LAG和LEAD函数能获取上/下行值，但必须明确ORDER BY定义逻辑顺序；无排序则结果不可预测；偏移量为n时取第n行值，越界返回NULL；需防NULL干扰和排序不稳定。
LAG 和 LEAD 函数到底能不能直接拿到上一行/下一行的值
能，但前提是必须明确指定排序依据。SQL 没有“天然行序”，LAG 和 LEAD 不是按物理存储顺序取值，而是严格依赖 ORDER BY 子句定义的逻辑顺序。不写 ORDER BY（或在窗口定义中漏掉），结果不可预测，甚至同一查询多次执行都可能不同。
常见错误现象：LAG(col) OVER () 报错或返回 NULL 居多——不是函数坏了，是窗口没定义排序。
- 必须写成
LAG(col) OVER (ORDER BY id)或LAG(col) OVER (PARTITION BY category ORDER BY created_at) - 如果业务上“上一行”指时间最近的前一条，
ORDER BY created_at DESC会导致LAG取到更早的时间点，注意方向匹配 - MySQL 8.0+、PostgreSQL、SQL Server 2012+、Oracle 支持；SQLite 3.25+ 支持；旧版 MySQL（5.7 及之前）不支持，需用自连接或变量模拟
偏移量设为 2 或更大时要注意什么
LAG(col, 2) 表示取当前行向上数第 2 行的值，不是“前两行的拼接”。它仍只返回一个标量值，且越界时默认返回 NULL（可指定替代值）。
容易踩的坑：
- 当排序后首两行调用
LAG(col, 2)，必然返回 NULL——没有“第 -1 行”可取 - 想取“前一行和前两行”，要写两个独立调用：
LAG(col, 1) AS prev1,LAG(col, 2) AS prev2，不能靠一次调用展开 - 偏移量过大（比如
LEAD(col, 1000)）不会报错，但若后续不足 1000 行，一律补 NULL；性能不受影响，因为窗口计算本身已排序完成
NULL 值干扰判断时怎么安全比较
直接写 col > LAG(col) 在 LAG 返回 NULL 时整条表达式结果为 NULL（三值逻辑），导致 WHERE 过滤失效或 CASE 分支不命中。
实操建议：
- 显式处理 NULL：
col > COALESCE(LAG(col), col - 1)（假设 col 是数字且单调增） - 用
IS DISTINCT FROM（PostgreSQL/SQL Server）代替!=，它把 NULL 视作普通值参与比较 - 更通用做法：加辅助标记列，例如
LAG(col) IS NOT NULL AS has_prev，再在外部 WHERE 或 CASE 中组合使用
和自连接比，LAG/LEAD 的性能差异在哪
窗口函数通常快一个数量级。自连接（如 t1.id = t2.id - 1）触发嵌套循环或哈希连接，数据量大时 I/O 和内存压力明显；而 LAG/LEAD 在排序后的单次扫描中完成所有偏移取值。
但有两个关键前提：
- 排序字段必须有索引，否则
OVER (ORDER BY timestamp)会强制排序，抵消窗口函数优势 - 如果同时需要多列偏移（如前一行的
user_id、amount、status），写三个LAG比自连接一次查三列更轻量——窗口只扫一遍，自连接要关联三次 - 分区场景下（
PARTITION BY user_id ORDER BY ts），自连接几乎无法高效实现等价逻辑，而窗口函数天然支持
真正容易被忽略的是排序稳定性：如果 ORDER BY 字段存在重复值（比如多个记录同秒创建），数据库可能每次返回不同相对顺序，导致 LAG 结果抖动。必要时加唯一字段兜底，例如 ORDER BY created_at, id。
