LEAD()必须配ORDER BY，否则结果不可靠；不加PARTITION BY则全表混算，加了才按业务分组；排序字段重复时需加唯一键兜底，且须处理NULL和除零问题。
LEAD() 必须写 ORDER BY，否则结果完全不可靠
不加 ORDER BY 的 LEAD() 在绝大多数现代 SQL 引擎（PostgreSQL、SQL Server、Oracle、MySQL 8.0+）中会直接报错；少数旧版本（如 MySQL 5.7）虽不报错，但返回值是随机的——因为“下一行”这个概念本身依赖明确的物理顺序。你看到的增长率忽正忽负、城市间数据串行，八成是漏了这句。
常见错误写法：LEAD(amount) OVER () —— 这等于没定义顺序，数据库按存储顺序或优化器喜好随便排。
正确做法必须显式声明排序逻辑：
- 时间类分析一律用真实时间字段，比如
ORDER BY event_time或ORDER BY ym（不能只用id代替时间） - 多级时间需完整排序：跨年月度分析要写
ORDER BY year, month，否则 2024-12 和 2025-01 可能被断开 - 排序字段含重复值（如秒级日志里多个同秒事件）时，建议补一个唯一字段兜底：
ORDER BY event_time, log_id
多业务线/用户/产品必须加 PARTITION BY，否则趋势全乱
没加 PARTITION BY 的 LEAD() 会把全表当一个大组排序，A 用户的最后一条记录后面，可能接的是 B 用户的第一条——这种“跨用户增长”毫无业务意义，但错误非常隐蔽，容易被当作噪声忽略。
典型场景包括：用户行为路径、分地区销售、按产品线看库存周转。只要逻辑上需要“各自独立往前看”，就必须分区：
- 查每个用户的下次登录时间：
LEAD(login_time) OVER (PARTITION BY user_id ORDER BY login_time) - 各城市月度客流环比：
LEAD(footfall) OVER (PARTITION BY city ORDER BY ym) - 漏掉
PARTITION BY却写了ORDER BY ym→ 所有城市的 2024-01 混在一起排，结果完全失真
NULL 和除零问题不是边缘情况，而是默认行为
LEAD() 对最后一行天然返回 NULL，而用它做增长率计算时，(next_value - current_value) / current_value 遇到 current_value = 0 就会报错。这两个问题不是“偶尔出现”，而是每次查询都必然发生。
稳妥写法要同时处理两种风险：
- 用
NULLIF(current_value, 0)替代直接除，避免除零错误 - 给
LEAD()显式设默认值，比如LEAD(sales, 1, 0)，比让它返回NULL更利于后续条件过滤或聚合 - 如果业务上“无下期”应视为 0 增长，可套
COALESCE(LEAD(...), 0)，但注意这会掩盖真实缺失（比如数据截断），需结合业务判断
偏移量 offset 和默认值 default 不是可选项，而是控制精度的关键参数
只写 LEAD(value) 等价于 LEAD(value, 1, NULL)，看似省事，实则埋雷：首行/末行大量 NULL 会污染整个指标链（比如后续再 SUM() 或 AVG() 就得额外 WHERE IS NOT NULL 过滤）。
根据场景选参数组合：
- 看“下一周销量”：用
LEAD(sales, 7)，前提是数据按天粒度且连续；若中间缺天，偏移 7 行可能跳到下周二，而非自然周 - 防
NULL中断计算：用LEAD(status, 1, 'unknown')比留空更利于WHERE status != 'unknown'控制范围 - 想跳过周末？单靠
offset不行，得先用ROW_NUMBER()或日期函数生成工作日序号再分区
实际中最容易被忽略的，是排序字段的业务含义和分区边界的对齐——比如用 created_at 排序却按 user_id 分区，看起来没问题，但如果某用户存在跨时区操作或时钟回拨，created_at 顺序就不可信。这时候得考虑是否该用业务侧生成的单调递增序列号替代时间戳。
