lead()取后一行、lag()取前一行，均需配合order by使用；可设偏移量和缺省值；分区计算须加partition by；null参与运算结果为null，需用coalesce或case处理。
LEAD() 和 LAG() 的基本用法与方向区别
LEAD() 取后一行，LAG() 取前一行，两者都必须配合 ORDER BY 使用，否则结果不可预测。不指定排序时数据库可能按物理存储顺序返回，看似“正常”，但一换环境或加索引就出错。
它们默认取相邻行（偏移量为 1），但可以显式传入第二个参数控制步长，比如 LAG(sales, 2) 表示取上上行的 sales 值。第三个参数是缺省值，当越界（如第一行调用 LAG()）时返回该值，不填则为 NULL。
- 必须写
OVER (ORDER BY ...)，不能只写OVER () - 排序字段最好具有唯一性，否则相同排序值的行之间顺序不确定，
LEAD()/LAG()结果可能每次执行都不一样 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 支持；旧版 MySQL 不支持，需用自连接模拟
计算前后行差值的典型写法
最常见需求是算“环比变化”，比如当前月销量减去上月销量。直接用 LAG() 拿上一行值再相减即可：
SELECT month, sales, sales - LAG(sales) OVER (ORDER BY month) AS diff_from_prev FROM sales_data;
注意：diff_from_prev 第一行一定是 NULL，因为没有“上一行”。如果想避免 NULL，得用第三参数补零或用 CASE 判断：
-
sales - COALESCE(LAG(sales) OVER (ORDER BY month), 0)—— 强制把首行差值设为sales CASE WHEN LAG(sales) OVER (ORDER BY month) IS NULL THEN 0 ELSE sales - LAG(sales) OVER (ORDER BY month) END
若要算“下月减本月”，就换成 LEAD(sales) - sales，逻辑对称，但最后一行会是 NULL。
分区场景下容易漏掉 PARTITION BY
当数据按类别分组（如不同产品线、不同地区）各自计算差值时，必须加 PARTITION BY，否则跨组混算。例如每个 product_id 独立算月度变化：
SELECT product_id, month, sales, sales - LAG(sales) OVER (PARTITION BY product_id ORDER BY month) AS diff_per_product FROM sales_data;
漏写 PARTITION BY product_id 的后果是：所有产品的数据被当成一个序列排序，A 产品最后一个月和 B 产品第一个月强行相减，数值完全无业务意义。
-
PARTITION BY必须在ORDER BY前，语法顺序固定 - 分区字段类型要一致，比如
product_id是字符串但有前后空格，会导致同产品被拆成多个分区 - 复合分区如
PARTITION BY region, category是合法的，但要注意组合键是否真能唯一标识业务逻辑上的“独立序列”
性能与 NULL 处理的实际坑点
LEAD()/LAG() 是窗口函数，不触发数据重排，性能通常比自连接好，但排序本身仍需资源。真正容易出问题的是 NULL 参与运算：一旦 LAG(sales) 返回 NULL，整个 sales - LAG(sales) 就变成 NULL（SQL 中任何值与 NULL 运算结果都是 NULL）。
- 别依赖“没看到 NULL 就代表没问题”——检查原始数据里是否有
sales IS NULL的行 - 排序字段含
NULL时，ORDER BY month默认把NULL排最前或最后（依数据库而定），导致LAG()拿到的是NULL而非真实上一行值 - 某些场景需要“跳过 NULL 取最近非空值”，这时
LAG()不够用，得结合FIRST_VALUE() OVER (... ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)或子查询
真正难的不是写对语法，而是确认业务上“缺失值怎么定义”“边界怎么处理”“分区是否干净”。这些没法靠函数自动解决。
