能，LEAD和LAG必须配合ORDER BY排序才能跨行取值，否则报错或结果不可预测；其行为严格依赖窗口定义的排序逻辑，而非插入顺序或主键顺序。
LEAD 和 LAG 函数到底能不能跨行取值？
能，但必须配合 ORDER BY 明确排序逻辑，否则结果不可预测。这两个函数不是“自动按插入顺序”或“主键顺序”取值，而是严格依赖窗口定义中的排序——没写 ORDER BY 就直接报错（如 PostgreSQL）或返回随机值（如某些 MySQL 8.0 配置下）。
- 常见错误现象：
LAG(value) returns NULL for all rows，往往是因为ORDER BY字段含大量重复值，且未加二级排序，导致窗口无法稳定确定“上一行”是谁 - 使用场景：比对相邻时间点的指标变化（如日活、库存）、识别状态切换（
'active'→'inactive'）、标记连续相同值的首尾行 - 参数差异：
LAG(col, 1, 0)中的0是默认值，当无前一行时返回0；省略第三个参数则返回NULL，注意后续WHERE或计算中是否做了空值处理
为什么 WHERE 条件里不能直接用 LAG/LEAD？
因为窗口函数在 SQL 执行顺序中晚于 WHERE —— 数据还没“算出上一行的值”，WHERE 就已经筛过一遍了。想基于比对结果过滤，必须把窗口计算放到子查询或 CTE 里。
- 常见错误现象：
WHERE LAG(status) = 'active'报错invalid reference to FROM-clause entry（PostgreSQL）或语法错误（MySQL） - 实操建议：用 CTE 包一层，例如
WITH t AS (SELECT *, LAG(status) OVER (ORDER BY ts) AS prev_status FROM events)，再SELECT * FROM t WHERE status != prev_status - 性能影响：CTE 不是物化视图（多数引擎下），但合理使用索引字段做
ORDER BY可避免全表排序；避免在LAG中嵌套复杂子查询
LEAD(LAG()) 嵌套能实现隔行比对吗？
能，但没必要。直接用 LAG(col, 2) 或 LEAD(col, 3) 更清晰、更高效。嵌套调用不仅可读性差，还可能放大空值传播风险——比如内层 LAG 返回 NULL，外层再 LAG 一次，逻辑就容易失控。
- 使用场景：检测“跳变”模式，如价格连续两期上涨：
price > LAG(price, 1) AND LAG(price, 1) > LAG(price, 2) - 参数差异：
LAG(col, n)的n是偏移量，不是“第几行”，LAG(col, 1)是前 1 行，LAG(col, 0)合法但等价于原列，不推荐 - 兼容性注意：SQLite 支持
LAG/LEAD但不支持第三个默认值参数；MySQL 8.0+、PostgreSQL、SQL Server、Oracle 均支持完整语法
分区（PARTITION BY）下比对失效怎么办？
分区后，LAG 只在每个分区内独立计算，“跨区”不连通。如果误以为整个结果集有序，却忘了加 PARTITION BY user_id，就会发现用户 A 的最后一行和用户 B 的第一行被错误关联。
- 常见错误现象：状态切换标记出现在用户边界处，比如
user_id=100最后一行是'active'，user_id=101第一行是'inactive'，却被判为“状态变更” - 实操建议：先确认业务语义是否真需要分区；若需跨用户全局序，就别用
PARTITION BY，改用唯一时间戳或自增 ID 做ORDER BY - 性能影响：分区字段若无索引，
OVER (PARTITION BY x ORDER BY y)可能触发多次排序，尤其当分区粒度细（如每用户几百行）、分区数多时
最易被忽略的是排序字段的稳定性：用 created_at 排序时，如果存在毫秒级相同值，不同数据库可能产生不同行序，导致 LAG 结果不一致。加一个唯一辅助字段（如 id）作为二级排序，能彻底规避这个问题。
