LAG和LEAD必须同时配PARTITION BY与ORDER BY才可靠：缺PARTITION BY则全表成一区，缺ORDER BY则行为未定义；FIRST_VALUE/LAST_VALUE默认帧不覆盖全分区，需显式声明ROWS UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING。
LAG 和 LEAD 必须配 PARTITION BY + ORDER BY 才可靠
不加 PARTITION BY 时，整个结果集被当成一个分区；漏掉 ORDER BY 则行为未定义——多数数据库（如 postgresql、SQL Server）会报错，mysql 8.0+ 虽允许但返回随机行偏移，结果不可复现。
- 业务场景中，90% 的错误源于只写
ORDER BY却忽略PARTITION BY：比如查每个用户最近两次登录间隔，没按user_id分区，就会跨用户取值 -
LAG(col, 1)默认取前 1 行，但若上一行不在同一分区内（例如分区边界），返回NULL—— 这是正确行为，不是 bug - 性能上，窗口函数依赖排序，
ORDER BY字段必须有索引，否则大表查询可能慢几秒甚至超时
FIRST_VALUE / LAST_VALUE 默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
这个默认窗口帧（frame）常导致误解：比如想取“每个分组第一条记录的金额”，却在 ORDER BY create_time 下用了 FIRST_VALUE(amount)，结果拿到的是当前行之前（含当前行）最小时间对应的值，而非整个分区的第一条。
- 要取整个分区首/尾，必须显式声明
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING - PostgreSQL 和 oracle 支持简写
ROWS UNBOUNDED，但 MySQL 8.0+ 不支持，必须写全 -
LAST_VALUE尤其危险：不改 frame 时，它几乎总等于当前行值，因为默认范围不包含后续行
LEAD(n) 超出分区末尾返回 NULL，但不能靠它判断“是否为最后一条”
有人用 LEAD(id) IS NULL 当作“当前行是该用户最后一条记录”的条件，这在单分区、严格按时间排序时看似可行，但实际脆弱。
- 如果存在并列时间（
create_time相同），ORDER BY create_time无法保证稳定排序，LEAD可能跳过或错位 - 更可靠的方式是配合
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC)，然后筛rn = 1 - 另外，
LEAD(col, 2)在倒数第二行会返回NULL，不是因为数据缺失，而是因为没有“后两行”——这点容易被当成脏数据误处理
时序分析中混用聚合和窗口函数容易触发 SQL 错误
比如写 select user_id, AVG(LAG(amount)) OVER (...) FROM t，MySQL 和 PostgreSQL 都会报错：Window function is not allowed in aggregation。
- 窗口函数不能嵌套在聚合函数里，也不能出现在
GROUP BY子句或HAVING条件中（除非外层是窗口） - 常见替代：先用子查询或 CTE 算出
LAG值，再对外层结果做AVG - BigQuery 允许
AVG(LEAD(x)) OVER(...)，但这是特例，别默认其他引擎也支持
时序分析真正卡住人的地方，往往不是语法记不住，而是默认窗口帧、排序稳定性、NULL 边界这些隐含规则在不同数据库里的细微差异——调通一条语句后，换环境或加个索引，就可能跑出不一样结果。