LAG函数必须配合ORDER BY使用，否则结果不可预测；需结合PARTITION BY分组、COALESCE处理NULL，并确保排序字段唯一且有索引支持。
LAG 函数必须配合 ORDER BY 使用，否则结果不可预测
很多人写完 LAG(order_time) 就直接跑查询，发现返回的“上一笔”时间完全不对——根本原因是没指定排序逻辑。LAG() 不按表物理顺序取值，而是严格依赖窗口定义里的 ORDER BY。订单时间本身不能直接当排序依据（可能有重复、乱序或 NULL），推荐用 order_id 或带时间戳的唯一字段：
LAG(order_time) OVER (PARTITION BY user_id ORDER BY order_id)。如果业务上允许按时间排序，也得先确保
order_time 非空且已去重校验。
NULL 值处理不加 COALESCE 会导致间隔计算中断
首笔订单的 LAG(order_time) 必然为 NULL，若直接做减法：order_time - LAG(order_time)，整行结果会变成 NULL。这不是 bug，是 SQL 的三值逻辑行为。实际计算转化间隔时，必须显式兜底：
COALESCE(order_time - LAG(order_time) OVER (PARTITION BY user_id ORDER BY order_id), INTERVAL '0' DAY)。注意 PostgreSQL 用
INTERVAL，MySQL 用 0，SQL Server 用 0（但类型需匹配 DATEDIFF）。
跨用户分组必须用 PARTITION BY，漏写就变成全局错位
如果不加 PARTITION BY user_id，LAG() 会把所有订单拉成一个大序列，张三的第二单可能取到李四的第一单时间——这在分析用户行为路径时是致命错误。常见疏忽点：
- 误以为主键排序天然隔离用户，其实窗口函数只认
PARTITION BY - 用
GROUP BY替代PARTITION BY，导致聚合后无法访问明细行 - 在子查询里漏传分区字段，外层
PARTITION BY失效
user_id 组内 LAG() 是否真取自同用户上一行。性能敏感场景要避免在 ORDER BY 中用函数或表达式
比如写成 ORDER BY DATE(order_time) 或 ORDER BY CONCAT(user_id, '-', order_id)，会让数据库无法利用索引加速窗口排序，尤其在千万级订单表上可能拖慢数倍。最优实践是：
- 确保
PARTITION BY字段（如user_id）和ORDER BY字段（如order_id）上有联合索引 - 避免在窗口定义中转换数据类型，宁可在应用层格式化
- MySQL 8.0+ 和 PostgreSQL 支持窗口函数下推，但 SQL Server 2019 仍建议先过滤再开窗
EXPLAIN 看是否出现 WindowAgg 节点及排序代价。真实业务里最常被忽略的是时间精度问题：订单系统存的是 TIMESTAMP，但前端展示只到秒，而 LAG() 取出的毫秒级时间差可能导致“0 秒间隔”被误判为异常。别急着四舍五入，先确认业务定义的“间隔”最小单位是秒还是分钟。
