处理相邻行数据时，自连接是不是写起来挺麻烦？要写JOIN、建临时表，还得担心关联条件漏数据。LAG()和LEAD()这两个窗口函数就是为此设计的——它们能直接在当前行上下文中获取偏移后的值，干净利落。不过有个硬前提：必须配合ORDER BY使用，没有排序就没有“相邻”，函数要么报错，要么返回不可靠的结果。
LAG() 和 LEAD() 的核心作用就是替代自连接
它们的原理很简单：直接在当前行上下文中获取偏移后的值，不用写 JOIN、不用建临时表、也不用担心关联条件漏数据。关键前提是必须明确指定 ORDER BY——没有排序就没有“相邻”，这两个函数会直接报错或返回 NULL。
常见错误现象：LAG(value) OVER () 不带 ORDER BY 在 PostgreSQL 报错，在 MySQL 8.0+ 虽不报错但结果不可靠；SQL Server 要求 ORDER BY 必须存在。
- 必须配合
OVER (ORDER BY ...)子句，且排序字段最好有唯一性（如加id防止同时间戳导致顺序不确定） LAG()取前一行，LEAD()取后一行；默认偏移量是 1，可显式写成LAG(col, 1)或LEAD(col, 2)- 越界时默认返回
NULL，可用第三个参数指定默认值，比如LAG(amount, 1, 0)
按业务时间序列计算环比时怎么避免自连接
比如销售表 sales 有 date 和 revenue，要算“比前一天增长多少”，传统做法得 JOIN sales s1 ON s2.date = s1.date + INTERVAL '1 day'，容易因缺日期断链。用 LAG() 更稳：
SELECT date, revenue, revenue - LAG(revenue, 1) OVER (ORDER BY date) AS diff_from_prev_dayFROM sales;
注意点：
- 如果
date有重复，ORDER BY date会导致相同日期内行序不确定，建议补上id或time：ORDER BY date, id - 缺失某天数据时，
LAG()自动跳到上一个实际存在的行，不是“逻辑前一天”，这点和自连接行为不同——后者能强制对齐日历，前者对齐实际记录 - MySQL 8.0+、PostgreSQL 8.4+、SQL Server 2012+、Oracle 从 8i 就支持，但 SQLite 直到 3.25 才支持窗口函数
LEAD() 处理“下一个有效状态”类逻辑的典型陷阱
例如用户操作日志表 user_events 记录 user_id、event_type（'login'/'logout'）、ts，想查每次 login 后的 logout 时间。用 LEAD() 很自然：
SELECT user_id, ts AS login_ts, LEAD(ts) OVER (PARTITION BY user_id ORDER BY ts) AS next_tsFROM user_eventsWHERE event_type = 'login';
但这里容易踩坑：
PARTITION BY user_id必须加，否则不同用户的事件混在一起排序，LEAD()可能取到别人的数据- 如果某次 login 后没有 logout，
LEAD()返回NULL，不能直接当“超时”处理，得结合业务判断是否允许无配对 - 若日志中存在多个连续 login（异常情况），
LEAD()取的是紧邻下一行，未必是“对应 logout”，此时需额外过滤或用条件偏移（如LEAD(CASE WHEN event_type='logout' THEN ts END)）
性能差异：为什么 LAG/LEAD 通常比自连接快
数据库执行 LAG() 时一般只做一次全表扫描 + 排序，然后线性遍历输出；而自连接往往触发嵌套循环或哈希连接，尤其当关联字段无索引时，复杂度接近 O(n²)。
但要注意：
- 如果
OVER子句里ORDER BY字段没索引，排序成本可能很高，这时自连接配上date索引反而更快 - 某些旧版本 PostgreSQL（如 9.x）对复杂窗口函数优化不足，
LAG(col, 100)可能比LAG(col, 1)慢很多；新版本已改善 - Oracle 中
LAG()在并行查询下表现稳定，但自连接若未正确 hint，容易被优化器选错驱动表
真正麻烦的从来不是函数本身，而是排序依据是否真实反映业务顺序——时间字段有精度丢失、字符串时间没标准化、或者用本地时区导致跨日混乱，这些都会让“相邻”变成错位。
