使用LAG()计算相邻订单时间差需按用户分组并显式排序，配合数据库特定时间差函数处理单位与时区，同时预过滤脏数据以确保准确性。
用 LAG() 获取上一行订单时间
窗口函数计算相邻订单时间差，核心是拿到当前行和前一行（或后一行）的时间字段。最常用的是 LAG()：它能按指定排序取出前 N 行的值。关键点在于必须显式声明 ORDER BY —— 如果没写，结果不可预测，甚至可能每次执行都不一样。
常见错误是直接在未排序的表上用 LAG(order_time)，尤其当表没有主键或插入顺序不等于业务时间顺序时，差值完全失真。实际场景中，订单时间字段名可能是 created_at、order_time 或 submit_time，需先确认字段存在且非空。
-
LAG()默认取前 1 行，想算隔一行的差可用LAG(order_time, 2) - 若首条订单无“前一条”，
LAG()返回NULL，可配合COALESCE(LAG(...), current_timestamp)填充，但通常应保留NULL以示边界 - PostgreSQL / MySQL 8.0+ / SQL Server / BigQuery 都支持，SQLite 3.25+ 也支持，但旧版 MySQL（5.7 及之前）不支持窗口函数，会报错
This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'类似提示
用 EXTRACT() 或时间减法算出秒级/分钟级差值
拿到前后两列时间后，不能直接相减（多数数据库会报类型错误），得用对应数据库的时间差函数。注意单位：业务常关心“分钟内是否重复下单”或“用户平均等待多久”，而非原始微秒值。
不同数据库语法差异明显：
- PostgreSQL：
EXTRACT(EPOCH FROM (order_time - LAG(order_time) OVER (ORDER BY order_time)))得到秒数；除以 60 得分钟 - MySQL 8.0+：
TIMESTAMPDIFF(SECOND, LAG(order_time) OVER (ORDER BY order_time), order_time)；TIMESTAMPDIFF(MINUTE, ...)更直观 - SQL Server：
DATEDIFF_SECOND(LAG(order_time) OVER (ORDER BY order_time), order_time)（2016+）；老版本只能用DATEDIFF(s, ..., ...) - BigQuery：
UNIX_SECONDS(order_time) - UNIX_SECONDS(LAG(order_time) OVER (ORDER BY order_time))
别漏掉时区问题：如果 order_time 是 TIMESTAMP WITHOUT TIME ZONE，而实际数据跨时区，差值会偏移。建议统一转为 UTC 后再计算。
按用户分组计算，避免跨用户混算
真实订单表通常含 user_id，相邻订单必须是同一用户的才合理。否则会出现“用户 A 的最后一单”和“用户 B 的第一单”被强行相减，得到一个毫无意义的大负数或正数。
正确做法是在 OVER 子句里加 PARTITION BY user_id：
LAG(order_time) OVER (PARTITION BY user_id ORDER BY order_time)
漏掉 PARTITION BY 是线上查数时最隐蔽的坑——数据量小时看不出异常，一旦用户变多，统计指标（如“平均下单间隔”）会系统性偏高或震荡。
- 若需排除测试账号，可在
WHERE中提前过滤user_id NOT IN ('test_123', 'demo_user')，而不是靠窗口函数处理 - 多个排序条件更稳妥，例如
ORDER BY order_time, order_id，防止时间相同时因无稳定排序导致LAG()结果不一致 - 部分数据库（如 Redshift）对
PARTITION BY字段有数据倾斜敏感性，若某user_id订单超百万条，窗口计算可能变慢，这时要考虑是否改用应用层聚合
处理 NULL 和异常时间值
订单时间字段经常有脏数据：空值、远古时间（'1970-01-01'）、未来时间（'9999-12-31'）、格式错误字符串。这些会导致 LAG() 输出异常，或时间差计算爆出 NULL 或负数。
不要依赖前端清洗——窗口函数执行时已无法跳过某行。应在子查询或 CTE 中预处理：
- 用
WHERE order_time IS NOT NULL AND order_time > '2020-01-01' AND order_time 过滤明显异常 - 对字符串时间，先用
TRY_TO_TIMESTAMP()（Snowflake）或STR_TO_DATE()（MySQL）转换，失败则置为NULL后被 WHERE 排除 - 计算差值后加
WHERE time_diff_seconds > 0 AND time_diff_seconds （排除超 30 天的异常长间隔）
最易被忽略的是：即使加了 PARTITION BY 和严格 WHERE，如果某个用户只有一条有效订单，他的 LAG() 仍是 NULL，对应差值列全为 NULL。做 AVG 聚合时，数据库默认忽略 NULL，但若误用 COUNT(*) 而非 COUNT(time_diff_seconds)，分母就会虚高。
