窗口函数本身不直接计算工单处理时长，需先明确定义“处理完成”的时间点（如created_at与resolved_at或最新closed操作时间），再通过FIRST_VALUE/LAST_VALUE+IGNORE NULLS或ROW_NUMBER()筛选关键事件时间戳，最后做差值计算；须注意NULL处理、时区统一及SLA统计应在外层过滤而非窗口内。
窗口函数不能直接算工单处理时长，得先定义“处理完成”
窗口函数本身不负责时间计算，它只做分组内排序、累计、排名等。要统计处理时长，第一步必须明确哪两个时间点相减：比如 created_at 到 resolved_at，或到最近一次 status = 'closed' 的操作时间。常见错误是直接对原始记录用 LAG() 或 LEAD()，结果发现同一工单多条状态变更记录，导致时间差乱跳。
实操建议：
- 先用
ROW_NUMBER() OVER (PARTITION BY ticket_id ORDER BY updated_at DESC)找出每张工单的最新关闭记录 - 用子查询或 CTE 提前过滤出「已关闭」的工单快照，再和创建时间关联
- 避免在窗口函数里嵌套
MAX(resolved_at) - MIN(created_at)—— 这会跨行聚合，不是窗口函数本意
用 FIRST_VALUE + CASE 识别首次响应和最终解决
客服场景常需区分「首次响应时长」和「总处理时长」，这时不能只依赖单个字段。典型做法是用 FIRST_VALUE() 配合条件筛选，把不同事件的时间戳拎出来。
示例逻辑（PostgreSQL）：
SELECT
ticket_id,
FIRST_VALUE(CASE WHEN status = 'assigned' THEN updated_at END)
IGNORE NULLS OVER (PARTITION BY ticket_id ORDER BY updated_at) AS first_assigned,
FIRST_VALUE(CASE WHEN status IN ('resolved', 'closed') THEN updated_at END)
IGNORE NULLS OVER (PARTITION BY ticket_id ORDER BY updated_at) AS first_resolved,
created_at
FROM ticket_events;注意点：
-
IGNORE NULLS是关键，否则遇到 status 不匹配就返回 NULL，后续减法失败 - MySQL 8.0+ 支持
IGNORE NULLS，但旧版本要用ROW_NUMBER()+ 子查询模拟 - 如果工单可能反复打开/关闭，
FIRST_VALUE取的是「最早一次」，不是「最后一次」——需要改成LAST_VALUE并配RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
处理 NULL 和时区问题比写窗口函数还容易翻车
工单系统里 resolved_at 为空太常见，直接 resolved_at - created_at 会整行变 NULL；更麻烦的是数据库时区和应用层不一致，比如 DB 存 UTC，前端展示用东八区，差值看起来像 8 小时超时，实际没超。
稳妥做法：
- 统一用
COALESCE(resolved_at, NOW())做兜底（仅用于分析，别用于 SLA 考核） - 显式转换时区：
resolved_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'（PostgreSQL）或CONVERT_TZ(resolved_at, '+00:00', '+08:00')（MySQL） - 避免在窗口函数里做时区转换——先转好再进窗口，不然排序逻辑可能错乱
按 SLA 分组统计时，别在窗口函数里加 WHERE
想看「4 小时内解决的工单占比」，有人会写 COUNT(*) FILTER (WHERE duration_sec ，这其实不对：窗口函数的 <code>OVER 子句不支持 FILTER，那是聚合函数的语法。真要这么算，得先算出每张工单的 duration_sec，再在外层用普通 COUNT + GROUP BY。
正确链路：
- CTE 先算出每张工单的处理时长（含 COALESCE / 时区处理）
- 外层 SELECT 用
COUNT(*) FILTER (WHERE duration_sec 和 <code>COUNT(*)算分子分母 - 窗口函数只用来做「同团队内工单按时率排名」这类需求，比如
RANK() OVER (PARTITION BY team ORDER BY late_rate DESC)
真正难的不是窗口函数怎么写，而是业务规则怎么映射到时间点选取上——比如「用户回复后才算开始处理」这种逻辑，得先 join 用户消息表，再找最小时间戳，窗口函数只是最后一步搬运工。
