lead函数查不到下一行，是因为未正确指定窗口定义：必须搭配over(order by...)子句，排序字段需具唯一性或足够区分度，漏写order by或partition by会导致结果未定义、跨组污染或报错。
LEAD 函数查不到下一行？先确认窗口定义是否正确
LEAD 本身不保证顺序，它只按你指定的 ORDER BY 子句排序后取“逻辑上的下一行”。如果没写 ORDER BY，结果是未定义的——多数数据库会报错，少数（如某些 MySQL 版本）可能返回任意行。
- 必须搭配
OVER (ORDER BY ...)，且排序字段要有唯一性或足够区分度，否则相同排序值的行之间“下一条”不可预测 - 不要在子查询或视图里漏掉
ORDER BY：即使外层有排序，LEAD 的窗口排序也必须显式声明 - 常见错误：
LEAD(value) OVER ()—— 空括号在标准 SQL 中非法，PostgreSQL 和 SQL Server 会直接报错Window definition must specify ORDER BY
LEAD 的 offset 和 default 参数怎么设才安全
LEAD 默认取下 1 行（offset = 1），但实际业务中常需要跳过几行，或处理末尾无后续数据的情况。这两个参数直接影响 NULL 行为和边界逻辑。
-
LEAD(column, 2)取后第 2 行，不是“后两行”，注意和LAG的对称性 -
LEAD(column, 1, 'N/A')在最后一行返回'N/A'而非NULL，避免上层应用空值异常 - 慎用
0作为 offset：SQL 标准不允许，PostgreSQL 报错frame start cannot be greater than frame end，SQL Server 直接拒绝
按分组查“组内下一条”时 PARTITION BY 容易漏写
想查每个用户最近两次登录间隔、每支股票每日涨跌幅，就必须按用户 ID 或股票代码分组。漏掉 PARTITION BY 会导致跨组污染——比如把用户 A 的最后一条记录和用户 B 的第一条混在一起算差值。
- 典型结构：
LEAD(login_time) OVER (PARTITION BY user_id ORDER BY login_time) - 注意
PARTITION BY字段必须出现在查询的 SELECT 或 GROUP BY 中（取决于上下文），否则某些数据库（如 Hive）会报错 - 如果分区字段有 NULL 值，不同数据库处理方式不同：PostgreSQL 把所有 NULL 归为同一组，Oracle 则每 NULL 单独成组——测试时务必覆盖 NULL 场景
性能隐患：ORDER BY 字段没索引，LEAD 就会变慢
LEAD 是窗口函数，执行时需全量排序。如果 ORDER BY 字段没索引，尤其是大表上，性能下降明显——不是线性增长，而是接近 O(n log n) 的排序开销。
- 检查执行计划：确认是否出现
Sort或WindowAgg节点，且对应字段无索引 - 复合索引优先考虑
(partition_col, order_col)，例如CREATE INDEX idx_user_time ON logs(user_id, event_time) - 避免在表达式上排序：如
ORDER BY DATE(created_at)会让索引失效，改用函数索引或提前计算列
ORDER BY 显式定义，哪怕只是加个主键。
