LAG()是版本对比最直接的窗口函数，因其专为“当前行与上一行比对”设计，无需分组聚合，仅需ORDER BY即可稳定获取前一版值，但须注意排序键唯一性、NULL处理及分区限制。
为什么 LAG() 是版本对比最直接的窗口函数
因为版本对比本质是「当前行和上一行的字段比对」，而 LAG() 就是专为这种「向下错位取值」设计的——它不依赖分组聚合，也不强制排序后重排数据，只要定义好 ORDER BY，就能稳定拿到前一版的值。
常见错误现象：LAG(col) OVER (ORDER BY version_time) 返回 NULL 很多，不是函数写错了，而是没处理好排序键重复或缺失；或者误以为 LAG() 能跨分区取值（比如用户A的最新版和用户B的上一版），其实它只在同一个 PARTITION BY 内生效。
- 必须显式写
ORDER BY，否则结果不可预测（SQL标准未定义无序窗口的偏移行为） - 若版本时间有重复，建议追加唯一列如
id：ORDER BY version_time, id - 想对比「上一有效版本」而非「物理上一行」，需先用
ROW_NUMBER()过滤掉无效快照，再套LAG()
如何用 LAG() 标出字段级变更点
版本对比不只是判断“是否变”，更要定位“哪里变了”。直接用 = 比对 LAG() 值会漏掉 NULL 场景，必须用 IS DISTINCT FROM（PostgreSQL）或手动展开判断（MySQL/SQL Server）。
使用场景：审计日志中追踪某配置项（如 status、price）每次修改的具体字段和旧值。
- PostgreSQL 推荐写法：
status IS DISTINCT FROM LAG(status) OVER (PARTITION BY item_id ORDER BY updated_at) - MySQL 8.0+ 需拆解：
COALESCE(status != LAG(status) OVER (...), TRUE)，但要注意 NULL != NULL 返回 NULL，所以更稳妥是(status LAG(status) OVER (...) OR (status IS NULL) != (LAG(status) OVER (...) IS NULL)) - 别在
WHERE子句里直接过滤LAG()表达式——窗口函数不能出现在 WHERE 中，得包一层子查询或 CTE
LAG() 和 LEAD() 混用时的排序陷阱
当既要查「上一版」又要查「下一版」，比如计算两次变更之间的时间差，容易下意识写两个窗口函数共用同一 OVER 子句。这本身没问题，但一旦 PARTITION BY 或 ORDER BY 不一致，两列偏移基准就错位了。
性能影响：多个 LAG()/LEAD() 共享同一窗口定义时，数据库通常只扫描一次；但如果窗口定义不同（比如一个按 created_at，一个按 id），可能触发多次排序。
- 确保所有窗口函数的
PARTITION BY和ORDER BY完全一致，除非你明确需要不同视角的偏移 - 计算时间差示例：
updated_at - LAG(updated_at) OVER (PARTITION BY user_id ORDER BY updated_at)—— 这里减的是上一版时间，不是上一行时间 - 如果源表没有严格单调递增的时间戳，先用
ROW_NUMBER()生成逻辑序号，再基于序号做LAG()，避免物理顺序干扰
兼容性差异：哪些数据库的 LAG() 默认行为最“坑”
MySQL 8.0+ 和 PostgreSQL 对 LAG() 的默认参数处理一致（第二参数省略即为 NULL），但 SQL Server 和 Oracle 在第三参数（offset）为负数或超范围时表现不同，且 SQLite 直到 3.25 才支持窗口函数。
容易踩的坑：在跨数据库项目里写 LAG(col, 2)，本意是取上上版，但在某些版本的 Hive 或旧版 Presto 中，会静默降级为 LAG(col, 1) 或报错。
- 显式指定默认值比依赖 NULL 更安全：
LAG(status, 1, 'unknown') OVER (...) - Oracle 用户注意：
LAG()不支持IGNORE NULLS（那是LAST_VALUE()的选项），想跳过 NULL 得提前用CASE过滤 - 测试时务必用真实数据覆盖边界：首行、末行、全 NULL 列、单行分区——这些地方最容易暴露兼容性问题
真正难的不是写出 LAG()，而是确认你的排序键在业务意义上能唯一锚定“上一版”。时间戳重复、批量导入导致顺序混乱、软删除记录混入——这些都会让窗口函数返回看似合理实则错误的对比结果。
