lead和lag返回null是因默认窗口范围导致边界无对应行，并非bug；需用coalesce或default子句处理，默认值选择取决于业务语义。
LEAD 和 LAG 函数为什么总返回 NULL？
因为默认窗口范围是 UNBOUNDED PRECEDING TO CURRENT ROW，而 LAG 需要“前面一行”，LEAD 需要“后面一行”——如果当前行是第一行，LAG 就没前一行；如果是最后一行，LEAD 就没后一行。这不是 bug，是设计如此。
- 显式指定
OFFSET参数（如LAG(sales, 1)）只是控制跨几行，不解决边界问题 - 用
COALESCE(LAG(value), 0)或COALESCE(LAG(value), value)填补 NULL，选哪个取决于业务语义：补 0 是“无变化即零”，补自身是“首行视作无变动” - PostgreSQL 和 BigQuery 支持
DEFAULT子句（如LAG(value, 1, 0)），但 MySQL 8.0+ 不支持，默认值必须靠COALESCE
按时间分组后算环比，为什么结果乱序或漏行？
窗口函数不改变原始行数，但依赖 ORDER BY 定义逻辑顺序。如果只写 ORDER BY created_at，但同秒有多条记录，排序就非确定性——导致 LAG 拿到的“上一条”可能是任意一条，环比计算失真。
- 必须把排序键打满：
ORDER BY created_at, id或ORDER BY created_at, event_id，确保每行位置唯一 - 如果数据按天聚合过（如
GROUP BY DATE(created_at)），先聚合再开窗；别在明细表上直接开窗然后GROUP BY，会双重聚合 - MySQL 中若用
DATE(created_at)排序，注意时区影响：created_at是 UTC 还是本地时间？错位一天就全错了
LAG(…, 2) 和连续两次 LAG(LAG(…)) 有啥区别？
看起来都能取“前两行”，但语义和稳定性完全不同：LAG(value, 2) 是跳过中间行、直取第 n 行；嵌套 LAG(LAG(value)) 是逐层向前推，中间任何一层为 NULL，结果必为 NULL。
-
LAG(value, 2)更快、更可控，推荐优先使用 - 嵌套写法常见于旧版 Hive（不支持多 offset），但现在没必要
- 注意：SQL 标准里
LAG的第三个参数是 default value，但 SQLite 和部分老版本 MySQL 不支持，得用COALESCE(LAG(value, 2), 0) - 性能上，单次
LAG(value, 2)只扫描一次窗口，嵌套调用可能触发多次窗口计算（尤其在 Spark SQL 中）
用 LEAD/LAG 做状态变化检测，怎么避免漏掉首尾状态？
比如查用户“首次登录 → 首次付费”的间隔，或订单“创建 → 支付 → 发货”的链路断点。LAG 只能看前一状态，LEAD 只能看后一状态，单独用都覆盖不全。
- 典型做法是自连接或用
ROW_NUMBER()配合条件过滤：先给每条状态打序号，再关联r1.status = 'created' AND r2.status = 'paid' AND r1.rn + 1 = r2.rn - 更轻量的是用
LEAD(status, 1) OVER (…)+LEAD(status, 2) OVER (…)同时拉出后续两个状态，再用CASE WHEN匹配模式 - 警惕重复状态：用户可能连续两条都是
'pending'，这时LEAD(status)看到的还是'pending'，不代表流程卡住——得加时间戳判断是否超时 - BigQuery 中可用
ARRAY_AGG(status ORDER BY ts LIMIT 2)提前聚合状态序列，比多次 LEAD 更直观
