SQL复杂状态流转查询_SQL多状态联动分析

SQL状态分析核心是将状态建模为带时间戳的事件序列，用窗口函数（如LAG/LEAD）识别流转路径、自连接判断多状态时序关系、递归CTE处理长链，并需统一时间精度、去重、标准化状态值。

SQL中处理复杂状态流转和多状态联动分析，核心在于把状态变化建模为“带时间戳的事件序列”，再用窗口函数、自连接或递归CTE梳理逻辑关系。不是简单查当前值，而是还原状态怎么一步步变过来、哪些状态必须先后发生、哪些不能共存。

用窗口函数识别状态流转路径

当一张表记录了对象（如订单、工单）每次状态变更的时间、旧状态、新状态、操作人，就可以用LAG()或LEAD()拉出前序/后续状态，判断是否符合业务规则。比如“审批中→已通过→已发货”是合法路径，“审批中→已发货”就该报警。

• 按对象ID + 时间排序，用LAG(new_status) OVER (PARTITION BY obj_id ORDER BY created_at)拿到上一个状态
• 加一列status_transition拼接“上一状态→当前状态”，便于统计高频路径或过滤异常跳转
• 配合COUNT(*) OVER (PARTITION BY obj_id)可识别被反复驳回的订单（状态来回变）

用自连接匹配多状态共存或互斥条件

有些分析要确认“某对象是否同时满足A状态和B状态（在不同时间点）”，比如“用户先完成实名认证，之后又开通了支付功能”。这时不能用WHERE status IN ('A','B')——那是查同一行含两个值。

• 把状态表自连接：FROM status_log t1 JOIN status_log t2 ON t1.user_id = t2.user_id
• 加条件限定时间顺序：t1.status = 'realname_verified' AND t2.status = 'payment_enabled' AND t1.created_at
• 若需排除“B状态后又退回A状态”的情况，可再加子查询检查中间是否出现干扰状态

用递归CTE还原完整状态链（适合审批流、工单升级等层级流转）

当状态变化有明确依赖（如“一级审核→二级审核→终审”），且每条记录只存当前节点和上级节点ID，就得用递归展开全路径。例如工单从提交到关闭，中间可能经历多次指派、驳回、重开。

标签： mysql 实名认证