lead是窗口函数，用于获取当前行之后第n行的值，必须配合over子句及order by排序使用；基本形式为lead(column, offset, default)，offset默认为1且须为正整数，default为越界时返回值。
LEAD 函数的基本用法和必要参数
LEAD 是窗口函数，用来取当前行之后第 N 行的值。它必须配合 OVER 子句使用，且至少要指定一个排序依据（ORDER BY），否则结果不可预测。
最简形式是：LEAD(column_name)，默认取下 1 行，偏移量为 1；如果想取下两行，得显式写成 LEAD(column_name, 2)。
常见错误：漏写 ORDER BY —— 比如在无主键、无索引的表上直接 LEAD(name)，数据库可能按任意物理顺序返回，导致“下一行”毫无业务意义。
-
LEAD第二个参数是偏移量，必须是正整数；传负数或 0 会报错（如 PostgreSQL 报ERROR: argument 2 of lead must be positive） - 第三个参数是默认值，当越界（比如最后一行再往后没有数据）时返回该值；不填则返回
NULL - 排序字段最好具备唯一性，否则相同排序值的多行之间顺序不确定，
LEAD可能跨组“跳行”
处理分组内下一行：PARTITION BY 的关键作用
实际业务中，往往需要“每个用户最近两条订单中，第二条的金额比第一条高多少”，这时不能全局排序，而要按用户分组后各自计算下一行。
必须用 PARTITION BY user_id 切分窗口，再在每个分区内独立应用 ORDER BY created_at。
典型陷阱：把 PARTITION BY 和 GROUP BY 混用。窗口函数不需要先聚合，加了 GROUP BY 反而会让 LEAD 失效（因为分组后只剩一行，没“下一行”可取）。
- 分区字段和排序字段逻辑要自洽：比如按
user_id分区、按created_at排序，但若某用户有两条时间完全相同的记录，仍可能顺序错乱 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持
PARTITION BY+LEAD，但 SQLite 目前不支持窗口函数 - 如果分区后某组只有一行，所有
LEAD调用都返回默认值（或NULL），需提前用COUNT(*) OVER (PARTITION BY ...)过滤掉单行组
LEAD 与 LAG 混用做相邻行差值计算
单纯取下一行值只是起点；更常见的是算变化量，比如“本单金额 - 下单金额”，这就需要同时用 LEAD 和 LAG，或者只用 LEAD 然后做减法。
例如计算相邻订单金额差：amount - LEAD(amount) OVER (ORDER BY order_id)，注意这里是“当前减下一行”，不是“下一行减当前”——顺序反了符号就错。
性能提示：多次调用 LEAD（比如同时取下 1 行、下 2 行）不会显著拖慢，因为窗口计算只做一次；但嵌套窗口函数（如在 LEAD 内再套 AVG OVER）可能触发重复扫描，需看执行计划。
- 别用
LEAD(amount, 1) - LEAD(amount, 2)来算“隔一行的差”，这其实等价于“第 n 行减第 n+1 行”，不是你想要的“第 n+1 行减第 n+2 行” - 日期类偏移慎用
LEAD(created_at, 1)直接减，因为可能跨天/跨月；建议先用LEAD取出下一行时间，再用数据库内置日期差函数（如AGE()或DATEDIFF()）计算 - 如果目标是“下一行比当前大”，直接写
LEAD(amount) > amount即可，不用先取出再 JOIN
替代方案：没有 LEAD 时怎么模拟（旧版 MySQL / SQL Server 2005）
MySQL 5.7 或 SQL Server 2005 不支持窗口函数，此时只能用自连接或子查询模拟 LEAD。核心思路是：对每行找满足“排序值刚好比它大一点点”的那一行。
例如按 id 递增模拟下一行：(SELECT amount FROM orders o2 WHERE o2.id > o1.id ORDER BY o2.id LIMIT 1)。但这个写法在大数据量下极慢，因为每行都要跑一次子查询，且无法利用 id 索引做高效跳跃。
真正可行的替代是自连接 + ROW_NUMBER()（如果支持），或导出到应用层用代码处理。强行在 SQL 里模拟 LEAD 往往得不偿失。
- LEFT JOIN 自身表时，条件写成
o1.id = o2.id - 1看似简洁，但前提是id严格连续、无删除——现实场景几乎不成立 - 用变量（如 MySQL
@rownum）实现行号再关联，语法脆弱、并发下易出错，官方已明确不推荐 - 如果只是偶尔查，接受
NULL结果，用LEAD是唯一合理选择；别为了兼容老版本牺牲可读性和维护性
真正容易被忽略的不是语法，而是排序字段的业务语义是否稳定——比如用 created_at 排序，但多个订单可能同毫秒插入，数据库内部又没强制唯一约束，这时候 LEAD 返回哪一行，连数据库自己都说不准。
