LEAD函数默认不跳过空值或业务无效记录，需用COUNT窗口函数生成分组号再配合FIRST_VALUE实现“向下找有效值”；对复杂有效性判断，预处理锚点表更高效。
LEAD 函数本身不支持“跳过空值找下一条有效记录”
直接用 LEAD() 默认只能取物理顺序的下一行，哪怕那一行的字段是 NULL 或业务上无效（比如状态为 'cancelled'、金额为 0），它也不会自动跳过。这不是 bug，是设计如此——LEAD() 只认窗口排序后的行号，不认业务逻辑有效性。
用 LEAD + 窗口聚合模拟“向下找有效值”的行为
核心思路：先给每条记录打一个“有效记录组号”，把当前行到下一个有效行之间的所有无效行归入同一组，再在组内用 MAX() 或 FIRST_VALUE() 拉取该组首个有效值。这比自连接更轻量，也避免了 N² 复杂度。
假设表 orders 有字段 id、status、amount，你想对每条 status = 'pending' 的记录，匹配它之后第一条 status = 'shipped' 的记录的 id：
SELECT id,
status,
amount,
FIRST_VALUE(CASE WHEN status = 'shipped' THEN id END)
OVER (PARTITION BY grp ORDER BY id) AS next_shipped_id
FROM (
SELECT *,
COUNT(CASE WHEN status = 'shipped' THEN 1 END)
OVER (ORDER BY id ROWS UNBOUNDED PRECEDING) AS grp
FROM orders
) t
WHERE status = 'pending';
这里 grp 是累计 shipped 记录数，相同 grp 值的 pending 行，都会被分配到“下一个 shipped 行所属的组”里；FIRST_VALUE() 在组内按 id 排序取第一个非空 id，就等价于“下一个有效 shipped 记录”。
- 必须用
ROWS UNBOUNDED PRECEDING，不能用默认的RANGE，否则同id值会出错 -
FIRST_VALUE()遇到全NULL会返回NULL，符合预期；不需要额外COALESCE - 如果“有效”定义复杂（如需校验多个字段+时间范围），把
CASE里的条件写严实即可
当数据量大且“有效记录稀疏”时，性能会明显下降
上面方案本质是靠 COUNT(...) OVER 扫描全表生成分组号，O(n) 时间但常数较大；若 shipped 记录只占 0.1%，却要为每条 pending 行都参与这个窗口计算，实际开销可能接近自连接。这时更稳的做法是预处理一张“有效记录锚点表”：
WITH shipped_anchor AS (
SELECT id AS shipped_id,
ROW_NUMBER() OVER (ORDER BY id) AS rn
FROM orders
WHERE status = 'shipped'
)
SELECT p.id,
p.amount,
s.shipped_id AS next_shipped_id
FROM orders p
LEFT JOIN shipped_anchor s
ON s.rn = (
SELECT MIN(s2.rn)
FROM shipped_anchor s2
WHERE s2.shipped_id > p.id
)
WHERE p.status = 'pending';
虽然用了子查询，但只针对 pending 行查一次 shipped_anchor 的最小 rn，B-tree 索引（shipped_id 上）能快速定位，整体更可控。
MySQL 8.0+ 和 PostgreSQL 支持直接用 LAG/LEAD 的 IGNORE NULLS（但仅限 NULL）
注意：这个语法只跳过真正的 NULL 值，对 'cancelled'、0 这类“业务无效但非 NULL”的情况完全无效。例如：
LEAD(amount) IGNORE NULLS OVER (ORDER BY id)
如果 amount 列本身允许 NULL，且你恰好用 NULL 表示无效，那这句就能用；但多数系统用状态码或标志位，此时 IGNORE NULLS 就是摆设。
真正难的不是语法，而是把“有效”的定义准确映射到窗口函数能理解的粒度——要么提前物化成 NULL，要么用聚合逻辑绕过去。漏掉这点，再花哨的窗口写法都会在上线后返工。
