lead函数需写为lead(status, 1) over (partition by ticket_id order by updated_at)，确保同工单内按时间严格排序；须预过滤status is not null，并硬编码异常状态流转规则。
LEAD函数怎么写才能拿到下一条工单记录
直接用 LEAD() 拿下一条状态，核心是按工单号分组、按时间严格排序。漏掉 PARTITION BY 或错用 ORDER BY 字段，会导致跨工单取值——比如把张三的“已关闭”和李四的“新建”连在一起判断，误报异常。
实操建议：
- 必须写
PARTITION BY ticket_id，确保只在同一条工单内向前看 -
ORDER BY created_at是底线；如果状态变更日志有毫秒级时间戳，优先用updated_at，避免同秒多条导致排序不稳定 - 别依赖默认偏移量：显式写
LEAD(status, 1)，不写第二个参数容易在嵌套查询里被意外覆盖 - 如果日志表存在脏数据（如
status为空），加WHERE status IS NOT NULL预过滤，否则LEAD()可能跳过有效行
哪些状态流转组合算“异常”要人工定义
数据库不会自动知道“新建→已关闭”是否合理，得靠业务规则硬编码。直接写死判断逻辑最稳，别试图用映射表动态加载——线上查异常时多一次 JOIN 就多一倍延迟，还可能因映射缺失漏报。
常见需拦截的异常模式：
-
'已关闭' → '处理中'（状态倒流） -
'已拒绝' → 任何非终态（拒绝后不可再激活） -
'新建' → '已关闭'（耗时 -
LEAD(status) IS NULL且当前不是终态（流程卡住，没后续动作）
示例片段：
WHERE (status = '已关闭' AND LEAD(status) OVER w = '处理中')<br> OR (status = '已拒绝' AND LEAD(status) OVER w NOT IN ('已关闭', '已撤销'))
性能差？多半是没建对索引
LEAD() 本身不慢，慢在窗口函数执行前要先完成排序。如果 tickets_log 表上没有复合索引，千万级数据下全表排序可能卡几秒。
必须建的索引：
-
(ticket_id, updated_at)—— 覆盖分组与排序需求，让PARTITION BY + ORDER BY直接走索引扫描 - 别只建
ticket_id单列索引，updated_at无序时仍要临时排序 - 如果常查某类工单（如
type = '投诉'），把该字段加入索引前导列，例如(type, ticket_id, updated_at)
为什么LEAD返回NULL却查不到异常工单
最常踩的坑：忘记 LEAD() 在窗口末尾天然返回 NULL，而你的 WHERE 条件里写了 LEAD(status) = 'xxx'，直接把最后一条记录过滤掉了——但“卡在终态没后续”本身就是一种异常。
正确做法：
- 用
IS NULL显式捕获末尾情况：LEAD(status) OVER w IS NULL AND status NOT IN ('已关闭', '已撤销', '已拒绝') - 别混用
COALESCE(LEAD(status), 'END')后再比对，字符串 'END' 可能和真实状态名冲突，引入假阳性 - 检查
updated_at是否有 NULL 值：如果有，ORDER BY updated_at会让这些行排在最前或最后（取决于数据库），打乱实际时序
状态流转分析本质是时序校验，关键不在函数多炫酷，而在每一步排序、分组、判空都贴合业务现实。少一个 PARTITION BY，或者索引缺一列，结果就不可信。
