LEAD函数必须配合ORDER BY使用，否则报错或结果不可靠；需用唯一键辅助排序防重复；offset默认为1，default值须与expression同类型；LEAD与LAG须共用同一窗口定义；WHERE过滤应在计算LEAD后进行。
LEAD 函数查不到下一行？先确认是否用了 ORDER BY
MySQL 的 LEAD() 是窗口函数，它不按表物理顺序取下一行，而是严格依赖 ORDER BY 子句定义的逻辑顺序。没写 ORDER BY，或者排序字段有重复值又没加唯一键辅助，结果就不可靠——常见表现是某些行返回 NULL，或“下一条”跳着走。
-
LEAD()必须配合OVER (ORDER BY ...)使用，单独写LEAD(col)会报错 - 如果
ORDER BY字段存在重复（比如多个用户同一天注册），MySQL 可能任意决定先后，导致LEAD()结果不稳定 - 稳妥做法：用主键或时间戳 + 主键组合排序，例如
ORDER BY created_at, id
LEAD() 的 offset 和 default 参数怎么设才不踩坑
LEAD() 默认取下 1 行（offset = 1），但最后一行没有“下一行”，默认返回 NULL。业务上常需要兜底值，比如把末尾的下一条设为 0 或 -1。
- 语法是
LEAD(expression, offset, default_value)，三者都得是同类型，否则隐式转换可能出错 - 如果
expression是INT，default_value写成字符串'N/A'会导致整列转成字符串类型，后续数值计算失效 - 常用兜底：
LEAD(score, 1, 0)、LEAD(name, 1, 'unknown')
和 LAG 混用时，排序方向必须一致
同一个查询里同时用 LEAD() 和 LAG() 时，它们共享同一个窗口定义。如果各自写不同的 ORDER BY，MySQL 8.0+ 会报错：Window 'w' cannot have multiple ORDER BY clauses。
- 正确写法：统一定义命名窗口，例如
OVER w AS (ORDER BY ts)，再在LEAD()和LAG()中复用w - 错误写法：
LEAD(x) OVER (ORDER BY ts)和LAG(x) OVER (ORDER BY id)—— 直接报错 - 如果真要不同排序逻辑，得拆成两个子查询，别硬塞进一个 SELECT
性能敏感场景：LEAD 配合 WHERE 会丢失窗口上下文
直接在主查询加 WHERE 过滤，会导致 LEAD() 计算基于过滤后的结果集，而非原始全集——这常被误认为“数据不准”。比如想查“每个用户最新一笔订单的下一笔订单”，若先 WHERE status = 'paid' 再用 LEAD()，那下一笔也只在 paid 订单里找，而不是所有订单里找。
- 正确做法：先用子查询或 CTE 算好全部
LEAD()值，再外层过滤 - 示例：
WITH ranked AS ( SELECT *, LEAD(order_id) OVER (PARTITION BY user_id ORDER BY created_at) AS next_order_id FROM orders ) SELECT * FROM ranked WHERE status = 'paid';
- 注意：
PARTITION BY要按业务分组粒度设，漏写会导致跨用户错连
窗口函数的边界行为和执行时机容易被忽略，尤其是和过滤、分组混用时；实际写的时候，先画出逻辑执行顺序，比死记语法更管用。
