lead()仅取下一行指定字段值，不合并行；必须配合over(partition by...order by...)使用，否则报错或结果不可预测，缺行时默认返回null，可设第三参数为默认值。
LEAD() 本身不合并行，它只取下一行的值
很多人以为 LEAD() 能“合并”两行，实际它只是把下一行某列的值，作为新列“拉”到当前行。真正显示“相邻两行数据并排”，靠的是在 SELECT 中同时引用当前行字段和 LEAD() 计算出的字段。
常见错误是写成 LEAD(col, 2) 想跳过一行，结果发现中间缺数据；或者没加 ORDER BY，导致“下一行”完全不可预测——LEAD() 必须配合明确的排序逻辑才有意义。
-
LEAD()是窗口函数，必须搭配OVER (ORDER BY ...)使用，否则报错 - 默认返回
NULL（当没有下一行时），可传第三个参数指定默认值，比如LEAD(name, 1, 'N/A') - 若需“当前行 + 下一行”拼成一个字符串（如
current_value + ' → ' + next_value），注意处理NULL：用ISNULL()（SQL Server）或COALESCE()（通用）包裹
按时间顺序合并前后两条记录的典型写法
假设有一张订单表 orders，含 id、user_id、amount、created_at，你想看每个用户“本次订单金额 → 下次订单金额”：
SELECT
user_id,
amount AS current_amount,
LEAD(amount, 1) OVER (PARTITION BY user_id ORDER BY created_at) AS next_amount,
CONCAT(
CAST(amount AS VARCHAR),
' → ',
COALESCE(CAST(LEAD(amount, 1) OVER (PARTITION BY user_id ORDER BY created_at) AS VARCHAR), 'first')
) AS amount_transition
FROM orders;
关键点：
-
PARTITION BY user_id确保“下一行”只在同一个用户内查找，避免跨用户错配 -
ORDER BY created_at决定哪条是“下一条”，时间戳必须精确到秒/毫秒，否则同秒订单顺序不确定 - 两次调用
LEAD()不影响性能，优化器会复用窗口计算；但若逻辑复杂，可考虑用 CTE 提前算好
遇到 NULL 导致拼接失败怎么办？
直接 CONCAT(col1, '→', col2) 在 col2 为 NULL 时，整个结果变成 NULL（尤其在 SQL Server 中）。这不是 LEAD() 的问题，而是字符串拼接的隐式规则。
- 用
COALESCE(next_amount, 'N/A')替代裸next_amount，强制提供非空占位符 - PostgreSQL 用户可用
||拼接，但同样要处理NULL：current || ' → ' || COALESCE(next, 'N/A') - MySQL 8.0+ 支持
CONCAT_WS(' → ', current, next)，它自动跳过NULL参数，更安全
LEAD() 和 LAG() 混用时的边界陷阱
如果既要“上一行金额”，又要“下一行金额”，写成 LAG(amount) OVER (...) AS prev 和 LEAD(amount) OVER (...) AS next 很自然——但要注意：这三行（prev / current / next）在结果集中是同一行输出，不是真的“合并了三行记录”。真正的“行数不变”是窗口函数的基本特性。
- 第一行永远没有
prev，最后一行永远没有next，这是设计使然，不是 bug - 若业务要求“只显示有 prev 且有 next 的中间行”，得加
WHERE prev IS NOT NULL AND next IS NOT NULL - 别在
WHERE或JOIN条件里直接引用LEAD()别名（如WHERE next_amount > 100），必须用子查询或 CTE，因为窗口函数执行晚于WHERE
PARTITION BY 和 ORDER BY 的组合是否真符合业务粒度。比如按用户分组但没按时间排序，或者按时间排序却忘了分区，结果“下一行”来自完全无关的人。这种逻辑错位，比语法错误更难排查。
