LAG需在OVER中显式写ORDER BY order_time，正确写法为LAG(order_time) OVER (PARTITION BY user_id ORDER BY order_time)；注意NULL处理、时间类型校验及数据库特有日期函数差异。
LAG函数怎么写才能正确获取上一条订单时间
直接用 LAG(order_time) 不够，必须指定排序依据，否则窗口函数返回结果是随机的。SQL 不会自动按时间排序，得显式写 ORDER BY order_time 在窗口定义里。
常见错误是漏掉 ORDER BY 或错放在外层查询中——窗口函数的排序必须在 OVER() 里声明。
- 正确写法：
LAG(order_time) OVER (PARTITION BY user_id ORDER BY order_time) - 如果只按时间排、不分用户，则去掉
PARTITION BY user_id - 注意：NULL 值会出现在每个分组第一条记录的
LAG结果中，这是正常行为
日期差值用DATEDIFF还是直接减法
不同数据库差异大，不能统一套用。MySQL 支持 order_time - LAG(order_time)（返回秒数），但 PostgreSQL 和 SQL Server 会报错；反之，SQL Server 的 DATEDIFF(day, ..., ...) 在 MySQL 里不存在。
安全做法是先确认数据库类型，再选对应函数：
- MySQL：
TIMESTAMPDIFF(HOUR, LAG(order_time) OVER (...), order_time)（单位可选 SECOND/MINUTE/HOUR/DAY） - PostgreSQL：
EXTRACT(EPOCH FROM (order_time - LAG(order_time) OVER (...))) / 3600得到小时数 - SQL Server：
DATEDIFF(MINUTE, LAG(order_time) OVER (...), order_time)
别硬套语法，DATEDIFF 的参数顺序、支持单位、是否包含边界，在各库中都不一致。
为什么计算出来全是NULL或0
两个高频原因：一是没处理 LAG 返回的 NULL（第一条记录必然为 NULL），二是时间字段类型不一致（比如 order_time 是字符串或带时区 timestamp，导致减法失败或精度丢失）。
- 检查
order_time是否为真正的TIMESTAMP或DATETIME类型，用SELECT pg_typeof(order_time)（PG）或DESCRIBE table_name（MySQL）验证 - 加
WHERE LAG(order_time) OVER (...) IS NOT NULL过滤首条记录，避免 NULL 参与运算 - 若时间含毫秒，而
DATEDIFF只取到天/小时，差值可能显示为 0 —— 换更细粒度单位或用EXTRACT精确计算
性能要注意窗口函数的排序开销
LAG 本身不慢，但 OVER (ORDER BY ...) 会触发全局排序，数据量过百万时可能明显拖慢查询。尤其当没在 order_time 上建索引，或 PARTITION BY 字段基数太高（比如按 order_id 分组）时，执行计划容易走全表扫描 + 文件排序。
- 确保
PARTITION BY和ORDER BY组合字段上有联合索引，例如(user_id, order_time) - 避免在子查询里嵌套多层窗口函数，先用 CTE 提取基础排序结果再计算差值
- 如果只要最近两次订单间隔，考虑用自连接替代窗口函数，有时反而更快
真实业务里，订单时间跨度大、用户量分散，LAG 的稳定性比绝对性能更重要——宁可加索引，别为了省几毫秒去拼接字符串模拟时间差。
