目录

1. 背景与问题

 2. 数据准备

2.1 表结构设计

3. 场景分析与实现

3.1 场景 1：检测非法状态转换

目标

实现

输出结果

3.2 场景 2：计算状态停留时长

目标

实现

输出结果（片段）

3.3 场景 3：跟踪完整状态路径

目标

实现

输出结果

3.4 场景 4：发现未完成订单

目标

实现

 4. 高级分析：递归查询状态树

目标

实现

输出结果

 5. 可视化与报警

5.1 可视化

5.2 报警机制

6. 性能优化

7. 总结

往期精彩

专栏优势：

我的专栏具体链接如下：

1. 背景与问题

在电商、物流或工单系统中，订单状态机是核心业务逻辑之一。状态机的正确流转直接影响用户体验和系统可靠性。例如：

• 合法路径：待支付 → 已支付 → 已发货 → 已完成

• 非法路径：待支付 → 已完成（跳过中间步骤）、已发货 → 待支付（非法回退）

本文将通过一个完整的案例，演示如何用 SQL 实现订单状态监控，涵盖以下场景：

1. 检测非法状态转换

2. 计算状态停留时长

3. 跟踪完整状态路径

4. 发现未完成订单

 2. 数据准备

2.1 表结构设计

记录订单状态变更历史：

CREATE TABLE order_state_history (
    order_id      INT,            -- 订单ID
    old_state     VARCHAR(50),    -- 旧状态（可为空，如初始状态）
    new_state     VARCHAR(50),    -- 新状态
    changed_at    TIMESTAMP       -- 变更时间
);

 2.2 插入测试数据

INSERT INTO order_state_history VALUES
(1001, NULL,      '待支付',  '2023-10-01 09:00:00'),
(1001, '待支付', '已支付',  '2023-10-01 10:15:00'),
(1001, '已支付', '已发货',  '2023-10-02 14:30:00'),
(1001, '已发货', '已完成',  '2023-10-05 16:45:00'),
(1002, NULL,      '待支付',  '2023-10-01 11:00:00'),
(1002, '待支付', '已取消',  '2023-10-01 12:00:00'),
(1003, NULL,      '待支付',  '2023-10-03 08:00:00'),
(1003, '待支付', '已支付',  '2023-10-03 09:30:00'),
(1003, '已支付', '已发货',  '2023-10-03 10:00:00'),
(1003, '已发货', '待支付',  '2023-10-03 11:00:00');  -- 非法回退

3. 场景分析与实现

3.1 场景 1：检测非法状态转换

目标

发现违反业务规则的状态跳转（例如 已发货 → 待支付）。

实现

使用 LAG() 获取前一个状态，定义合法转换规则：

WITH state_transitions AS (
    SELECT 
        order_id,
        new_state,
        LAG(new_state) OVER (PARTITION BY order_id ORDER BY changed_at) AS prev_state,
        changed_at
    FROM order_state_history
)
SELECT 
    order_id,
    prev_state,
    new_state,
    changed_at AS illegal_transition_time
FROM state_transitions
WHERE (prev_state, new_state) IN (
    -- 定义非法转换规则
    ('已发货', '待支付'),    -- 非法回退
    ('待支付', '已完成'),    -- 跳过步骤
    ('已支付', '已取消')     -- 未定义路径
);

输出结果

3.2 场景 2：计算状态停留时长

目标

分析每个状态持续的时间（例如“已支付”到“已发货”的间隔）。

实现

用 LEAD() 获取下一个状态的时间，计算差值：

SELECT 
    order_id,
    new_state AS current_state,
    changed_at AS start_time,
    LEAD(changed_at) OVER (PARTITION BY order_id ORDER BY changed_at) AS end_time,
    EXTRACT(EPOCH FROM 
        LEAD(changed_at) OVER (PARTITION BY order_id ORDER BY changed_at) - changed_at
    ) / 3600 AS duration_hours  -- 转换为小时
FROM order_state_history;

输出结果（片段）

3.3 场景 3：跟踪完整状态路径

目标

获取每个订单的状态变化轨迹（例如 待支付 → 已支付 → 已发货 → 已完成）。

实现

使用 STRING_AGG() 聚合状态序列（PostgreSQL 语法）：

SELECT 
    order_id,
    STRING_AGG(new_state, ' → ' ORDER BY changed_at) AS state_path
FROM order_state_history
GROUP BY order_id;

输出结果

3.4 场景 4：发现未完成订单

目标

找出超过 48 小时未从“已支付”变为“已发货”的订单。

实现

WITH latest_states AS (
    SELECT 
        order_id,
        new_state,
        changed_at,
        ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY changed_at DESC) AS rn
    FROM order_state_history
)
SELECT 
    order_id,
    new_state,
    changed_at AS last_state_time,
    NOW() - changed_at AS time_since_last_change
FROM latest_states
WHERE rn = 1
    AND new_state NOT IN ('已完成', '已取消')
    AND NOW() - changed_at > INTERVAL '48 hours';

 4. 高级分析：递归查询状态树

目标

检测订单是否经过标准路径 已支付 → 已发货 → 已完成。

实现

WITH RECURSIVE state_path AS (
    SELECT 
        order_id,
        new_state,
        changed_at,
        1 AS depth,
        ARRAY[new_state] AS path
    FROM order_state_history
    WHERE new_state = '待支付'
    UNION ALL
    SELECT 
        sp.order_id,
        h.new_state,
        h.changed_at,
        sp.depth + 1,
        sp.path || h.new_state
    FROM state_path sp
    JOIN order_state_history h 
        ON sp.order_id = h.order_id 
        AND h.changed_at > sp.changed_at
    WHERE sp.depth < 5
)
SELECT 
    order_id,
    path
FROM state_path
WHERE path @> ARRAY['已支付', '已发货', '已完成'];

输出结果

 5. 可视化与报警

5.1 可视化

将查询结果集成到 BI 工具（如 Metabase）：

• 状态流转图：展示各状态间的转换频率。

• 停留时长分布：直方图显示“已支付”到“已发货”的耗时分布。

5.2 报警机制

通过定时任务（如 Airflow）执行检测 SQL，触发报警：

# 伪代码：检测非法状态转换并发送通知
result = execute_sql("场景1的SQL")
if result.row_count > 0:
    send_alert_email("发现非法状态转换：", result.data)

6. 性能优化

索引优化

CREATE INDEX idx_order_state ON order_state_history (order_id, changed_at);

分区表
按 changed_at 按月分区，减少全表扫描。

物化视图
预聚合高频查询（如最新状态）。

7. 总结

通过 SQL 的窗口函数和递归查询，可高效实现订单状态机的监控与分析：

1. 精准检测异常：非法状态转换、流程跳跃。

2. 量化流程效率：状态停留时长、瓶颈定位。

3. 全链路追踪：从下单到完成的完整路径分析。

该方法可扩展至用户行为分析、设备状态监控等场景，为业务系统提供核心的“可观测性”能力。

往期精彩

3分钟学会SQL中的断点去重技术，轻松搞定连续相同状态数据去重问题？

颠覆认知！COUNT(DISTINCT) OVER(ORDER BY)  原生写法 VS 替代方案，谁才是王者？

企业级数据仓库改造方案：如何治理同命不同义的指标？

3分钟学会SQL中的断点分组技术，轻松搞定连续相同状态数据分组问题？

HyperLogLog 近似累计去重技术解析：大数据场景下的高效基数统计

宽表爆炸？动态Schema + 增量更新，轻松化解千字段扩展难题

如果您觉得本文还不错，对你有帮助，那么不妨可以关注一下我的数字化建设实践之路专栏，这里的内容会更精彩。 

专栏 原价99，现在活动价59.9，按照阶梯式增长，即将恢复到原价。

专栏优势：

（1）一次收费持续更新。

（2）实战中总结的SQL技巧，帮助SQLBOY 在SQL语言上有质的飞越，无论你应对业务难题及面试都会游刃有余【全网唯一讲SQL实战技巧，方法独特】

SQL很简单，可你却写不好？每天一点点，收获不止一点点_sql断点-CSDN博客 

（3）实战中数仓建模技巧总结，让你认识不一样的数仓。【数据建模+业务建模，不一样的认知体系】（如果只懂数据建模而不懂业务建模，数仓体系认知是不全面的）

（4）数字化建设当中遇到难题解决思路及问题思考。

我的专栏具体链接如下：

数字化建设通关指南_莫叫石榴姐的博客-CSDN博客https://blog.csdn.net/godlovedaniel/category_12706766.html