GROUP BY无法直接识别状态跃迁，因其是无序聚合操作，不保留行序；必须用窗口函数LAG()或自连接实现相邻行比较，核心是按设备分组、时间排序后比对当前与前一状态。
GROUP BY 本身不能直接找出状态跃迁记录
GROUP BY 是聚合操作，它把多行归为一组后返回单行结果（如 COUNT()、MAX()），但“状态跃迁”本质是**相邻行之间的比较问题**——比如某设备从 'offline' 变成 'online'，这需要知道前一条和后一条的值。GROUP BY 没有行序概念，也不保留原始行位置，所以单靠它做不到。
真正可行的是用窗口函数 + 自连接或LAG()比对
你需要先按时间/顺序排好数据，再逐行检查状态变化。最常用、最直观的方式是 LAG()：
SELECT id, status, updated_at
FROM (
SELECT id, status, updated_at,
LAG(status) OVER (PARTITION BY device_id ORDER BY updated_at) AS prev_status
FROM device_log
) t
WHERE status != prev_status AND prev_status IS NOT NULL;
关键点：
-
PARTITION BY device_id确保只在同一个设备内比较，避免跨设备误判跃迁 -
ORDER BY updated_at必须明确，否则LAG()返回顺序不可控 -
prev_status IS NOT NULL排除每组第一条记录（它没有前值） - 如果状态字段含空值，
!=判断会失效，应改用IS DISTINCT FROM（PostgreSQL）或显式处理NULL
MySQL 8.0+ 和旧版处理方式差异大
MySQL 8.0+ 支持 LAG()，写法同上；但 MySQL 5.7 或更早版本不支持窗口函数，只能用自连接模拟：
(device_id, updated_at)
- 只关心从
'pending'→'done'的完成跃迁，忽略中间'processing' - 连续相同状态多次更新（如反复设为
'warning'）不算跃迁，只算一次进入 - 状态字段大小写不敏感，但数据库默认区分，需统一用
UPPER(status)再比对
这些逻辑无法靠 GROUP BY 或简单 LAG 解决，得在 WHERE 条件里加具体判断，或者用 CTE 先清洗状态阶段。
