LAG()和LEAD()可直接配合时间字段计算单步耗时，需确保ORDER BY明确排序、PARTITION BY正确分组、时间字段为TIMESTAMP/DATETIME类型，否则易导致跨实体错连或计算错误。
窗口函数怎么配合时间字段算耗时
直接用 LAG() 或 LEAD() 拿上一行/下一行的时间戳，再用当前行减去它，就能得到单步耗时。关键不是函数本身，而是时间字段必须能排序且无歧义——比如同一用户、同一订单下的操作日志，得靠 ORDER BY event_time 明确先后，否则 LAG(event_time) 可能拉错行。
常见错误是漏写 PARTITION BY：如果数据跨多个业务实体（如不同用户的订单操作），不按 user_id 或 order_id 分组，LAG() 就会把张三的最后一步和李四的第一步连起来算耗时，结果完全失真。
- 必须确保时间字段类型为
TIMESTAMP或DATETIME，别用字符串存时间，否则减法可能报错或返回意外值 - PostgreSQL 和 MySQL 8.0+ 支持直接相减得 interval 或秒数；SQLite 需用
julianday()转换；SQL Server 建议用DATEDIFF(second, ...) - 若某步骤缺失（如日志丢失），
LAG()返回 NULL，耗时列也会是 NULL——这不是 bug，是数据事实，别急着用COALESCE填 0
如何计算整个流程总耗时（首尾时间差）
用 MIN(event_time) 和 MAX(event_time) 配合 PARTITION BY flow_id 最稳。比反复 LAG 累加更可靠，尤其当流程步骤数不固定、或中间有跳过环节时。
注意：如果流程里存在“并行操作”（比如两个子任务同时启动），MIN/MAX 仍有效；但若想排除并行干扰、只算主线路径，就得先用条件过滤出关键节点，再套窗口函数。
- 别用
FIRST_VALUE(event_time) OVER(...)替代MIN——除非你确定排序后第一行就是起点，否则可能因ORDER BY条件偏差拿错“首” - MySQL 中
MIN/MAX窗口函数要求显式写ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，否则默认只算当前行及之前，结果偏小 - 某些场景下起点和终点事件类型不同（如
status = 'created'和status = 'completed'），得先用CASE WHEN提取时间，再聚合
耗时为负数？多半是时间乱序或时区没对齐
出现负值，基本可锁定两类问题：一是原始日志时间写入错乱（比如服务器时钟回拨、客户端本地时间未同步），二是多时区混用——比如前端传的是 UTC 时间，数据库存的是东八区时间，又没做转换就直接计算。
查问题最快的方式是加一列 LAG(event_time) OVER(PARTITION BY id ORDER BY event_time)，和当前 event_time 并排看，立刻暴露哪几行时间倒流。
- 上线前务必在 WHERE 中加校验：
event_time >= LAG(event_time) OVER(...)，把异常数据单独捞出来人工核对 - Oracle 用户注意：
SYSTIMESTAMP和CURRENT_TIMESTAMP时区行为不同，混用会导致跨节点计算出负值 - 如果业务允许容忍少量乱序（如移动端弱网延迟上报），可在窗口定义中加
RANGE BETWEEN INTERVAL '5' SECOND PRECEDING AND CURRENT ROW缓冲，但会牺牲精度
性能卡在窗口函数上？先看执行计划里的“WindowAgg”节点
窗口函数本身不慢，慢在数据量大时排序开销高。PostgreSQL 的执行计划里如果看到 WindowAgg 节点占总耗时 70% 以上，大概率是 ORDER BY 字段没索引，或者 PARTITION BY 列基数太低（比如全表只有 3 个 flow_type，导致每个分区过大）。
- 给
(flow_id, event_time)建联合索引，能显著加速带PARTITION BY flow_id ORDER BY event_time的窗口计算 - 避免在窗口函数里嵌套复杂表达式，比如
LAG(DATE_ADD(event_time, INTERVAL 1 HOUR))——先算好新时间存成临时列，再窗口引用 - ClickHouse 用户注意：
lagInFrame()比标准LAG()快得多，且支持多列同时 lag，别硬套 ANSI 写法
