LAG()算状态间隔出错因状态重复/乱序/缺失导致拉取错误前值；须先用ROW_NUMBER()保序，再用LAG()取上一状态与时间，并WHERE过滤真跳变。
为什么直接用 LAG() 算状态间隔经常出错
因为订单状态变更记录常有重复、乱序或缺失——比如同一状态被多次插入，或 created_at 时间戳精度不足导致并列，LAG() 会把上一条“非目标状态”的记录拉进来，算出负数或零耗时。关键不是函数不会用，而是没过滤干净有效状态跳转。
实操建议：
- 先用
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at, id)给每条变更打序号，避免时间相同时靠主键id排序保序 - 再用
LAG(status, 1) OVER (PARTITION BY order_id ORDER BY created_at, id)和LAG(created_at, 1) OVER (...)同步取上一状态和时间 - 外层必须加
WHERE status != LAG(status)，排除状态未变的“伪变更”
如何只统计“待支付 → 已支付”这类指定流转的耗时
窗口函数本身不支持跨行条件匹配，不能直接写 LAG(status) = 'pending' AND status = 'paid' 这种逻辑——因为 LAG() 是逐行计算，而判断需要两行联合约束。得靠子查询或 CTE 拆解。
实操建议：
- 第一层 CTE：用
LAG()提前取出上一状态、上一时间，别急着算差值 - 第二层 WHERE 中写
prev_status = 'pending' AND status = 'paid'，再用EXTRACT(EPOCH FROM (created_at - prev_created_at))算秒数 - 若数据库不支持
EXTRACT（如 MySQL），改用TIMESTAMPDIFF(SECOND, prev_created_at, created_at)
LEAD() 和 LAG() 在耗时统计里到底该选哪个
选 LAG()。因为耗时是“从上一状态到当前状态”，自然以当前行为基准，向上取前一行数据。用 LEAD() 虽然数学等价，但语义反直觉，且容易在过滤时漏掉末尾状态（比如订单最终是“已完成”，它后面没下一条，LEAD() 返回 NULL，这行就被丢弃了）。
常见错误现象：
- 用
LEAD()+WHERE next_status IS NOT NULL导致最后一条状态变更永远不参与计算 - 误以为
LEAD(created_at) - created_at更“顺向”，结果丢失终止态的停留时长（如“已发货”到“已完成”之间的时间） - 某些场景需统计“当前状态已持续多久”，才该用
LEAD()取下一次变更时间
时间精度陷阱：MySQL 5.7 和 PostgreSQL 的 created_at 处理差异
MySQL 5.7 默认 DATETIME 只到秒级，高并发下多条变更可能时间相同，LAG() 随机取其中一条，导致耗时算成 0。PostgreSQL 的 TIMESTAMP WITH TIME ZONE 默认微秒级，但若应用写入时截断了精度，问题一样出现。
实操建议：
- MySQL：确保字段是
DATETIME(6)，写入时用NOW(6)；查询中加ORDER BY created_at, id强制唯一排序 - PostgreSQL：检查是否用了
clock_timestamp()而非now()（后者事务内不变） - 统一在 SQL 层补兜底：
NULLIF(EXTRACT(EPOCH FROM (created_at - prev_created_at)), 0)，把 0 耗时转为 NULL，后续可单独排查
真正难的不是写出窗口函数，而是确认每条状态变更记录本身是否可信——时间戳来源、去重逻辑、业务定义的“有效变更”边界，这些比函数语法重要得多。
