lag()是计算订单状态变更时间差的唯一可靠方法，需按order_id分组、event_time排序，用coalesce处理首条null，并确保event_time为timestamp类型。
窗口函数怎么按订单ID分组计算状态变更时间差
直接用 LAG() 获取上一条记录的时间戳，再和当前行做减法，是唯一靠谱的路径。PostgreSQL 不支持在窗口函数里直接写 current_timestamp - previous_timestamp 这种表达式，必须显式用 LAG(event_time) OVER (PARTITION BY order_id ORDER BY event_time) 提前拉出前序时间。
常见错误是漏掉 ORDER BY event_time —— 没有明确排序，LAG() 返回的就是随机行的时间，算出来的耗时全是错的。另外注意 event_time 必须是 TIMESTAMP WITH TIME ZONE 或至少 TIMESTAMP 类型，别用 DATE 或字符串，否则减法会报错或返回天数而非秒级精度。
- 确保每条状态变更记录带精确到秒（或毫秒）的
event_time -
PARTITION BY order_id保证只在同一个订单内向前取值 - 第一次状态（如“已创建”）没有前序时间，
LAG()返回NULL，需用COALESCE处理，例如：COALESCE(event_time - LAG(event_time) OVER (...), INTERVAL '0')
如何把“支付→发货→签收”这类链路拆成可统计的阶段耗时
不能靠 CASE WHEN 硬编码判断前后状态，得先用窗口函数标记出每个订单的状态流转序列，再用自连接或子查询匹配相邻状态对。更稳的做法是：先用 ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY event_time) 给每条记录打序号，然后和自身做左连接，条件为 t1.order_id = t2.order_id AND t1.rn = t2.rn + 1，这样就能把“前一状态→后一状态”的组合拉平成一行。
典型陷阱是多个相同状态连续出现（比如两次“已取消”），如果只按状态名匹配，会误判为有效流转。应优先依赖 event_time 顺序，而不是状态字符串相等。必要时加 WHERE t1.status != t2.status 过滤掉无意义重复。
- 用
ROW_NUMBER()替代业务逻辑判断流转顺序，避免状态名歧义 - 连接时用
t1.rn = t2.rn + 1而非模糊的时间范围，保证严格相邻 - 阶段耗时字段建议命名为
duration_seconds并转成EXTRACT(EPOCH FROM (t1.event_time - t2.event_time))，方便后续聚合
为什么用 LEAD() 反而更容易出错
LEAD() 在分析“从A到B用了多久”时看似顺直，但实际容易漏掉最后一环：比如一个订单停留在“已发货”，还没签收，LEAD(event_time) 就是 NULL，导致整条记录被 WHERE lead_time IS NOT NULL 过滤掉，最终统计样本不全。而 LAG() 至少能保留所有记录，只是首条为 NULL，不影响整体分布观察。
另一个问题是语义混淆：写 LEAD(status) 得到的是“下一个状态”，但你真正要算的是“当前状态持续了多久”，这个时长其实由下一次变更触发，所以用 LEAD(event_time) - event_time 才对。但一旦有人把 LEAD(status) 和 LAG(event_time) 混着用，结果就完全不可信。
- 除非明确只分析已完成闭环的订单（如已签收且无后续变更），否则慎用
LEAD()做主逻辑 -
LEAD()的默认参数是LEAD(col, 1, default_value)，第三个参数填NULL或当前时间都得想清楚业务含义 - 测试时务必查几单
status = '已签收'的记录，确认它们的LEAD(event_time)是否真为NULL
性能差？多半是没给关键字段建索引
窗口函数本身不慢，慢的是排序和分区。当订单表超千万行，又没索引时，PARTITION BY order_id ORDER BY event_time 会强制全局排序，I/O 和内存开销陡增。解决方法很简单：建一个复合索引 CREATE INDEX idx_order_event_time ON orders (order_id, event_time)。
注意别只建 order_id 单列索引——它对 ORDER BY event_time 几乎无效；也别用 event_time 单独索引，无法加速分区。这个索引还能顺便提升按订单查全生命周期的响应速度。
- 建索引前先
EXPLAIN ANALYZE看执行计划，确认是否走了WindowAgg+Sort的高成本路径 - 如果表经常写入，考虑用
CONCURRENTLY选项建索引，避免锁表 - 分区表用户注意：索引需在每个子表上单独创建，父表上的索引不自动继承
实际跑起来你会发现，最耗神的不是写 SQL，而是确认每条状态变更事件的业务定义是否统一——比如“支付成功”是指支付网关回调完成，还是财务系统确认入账？这种边界不清晰，窗口函数再准也没用。
