lag本身不维护状态，所谓“动态状态机”必须靠外部逻辑显式定义和驱动；累加和（如sum() over）只能提供累计计数或指标，不能替代状态跃迁判断。lag只负责取值，状态转换逻辑必须写在case或where中。
LAG 本身不维护状态，所谓“动态状态机”必须靠外部逻辑显式定义和驱动；累加和（如 SUM() OVER）只能提供累计计数或指标，不能替代状态跃迁判断。
LAG 只负责取值，状态转换逻辑必须写在 CASE 或 WHERE 中
很多人误以为 LAG(status) 自带“状态识别”能力，其实它只返回字符串或数字——比如 LAG(status) 返回 'pending'，但“从 pending 到 shipped 算一次发货完成”这个规则，得你用 CASE WHEN status = 'shipped' AND LAG(status) OVER (...) = 'pending' THEN 1 ELSE 0 END 显式写出。否则数据库根本不知道什么叫“完成”。
- 漏写
PARTITION BY order_id：不同订单状态混排，LAG()可能从 A 订单末尾取到 B 订单开头的值，状态链彻底断裂 - 没加
ORDER BY event_time, event_id：同一秒多事件时序不确定，LAG()拿到的“前一状态”可能是任意一个，流转分析失真 - 直接在
WHERE里嵌套LAG()表达式（如WHERE LAG(status) = 'confirmed'）：部分数据库（如旧版 MySQL）不支持，且语义模糊、执行计划难优化
SUM() OVER 做的是累计计数，不是状态赋值
有人想用 SUM(CASE WHEN status = 'shipped' THEN 1 ELSE 0 END) OVER (PARTITION BY order_id ORDER BY event_time) 来标记“第几次发货”，这确实可行，但它生成的是整数序列（1, 2, 3…），不是状态值（'shipped_1', 'shipped_2'）。若要构造复合状态，仍需配合 CASE + 字符串拼接：
SELECT *,
CASE
WHEN status = 'shipped' THEN
'shipped_' || CAST(SUM(CASE WHEN status = 'shipped' THEN 1 ELSE 0 END)
OVER (PARTITION BY order_id ORDER BY event_time) AS VARCHAR)
ELSE status
END AS enriched_status
FROM events;
-
SUM() OVER的排序必须与业务时序严格一致，否则累计顺序错乱（例如按id排而非event_time） - MySQL 8.0+ 支持该写法，但 PostgreSQL 需用
||，SQL Server 得改用+，跨库迁移时注意字符串连接符差异 - 累计字段无法回退——一旦某行被标为
shipped_2，后续即使删掉中间一条 shipped 记录，该累计值也不会自动减 1
真正需要“状态机”语义时，优先拆解为 CTE 步骤
复杂流转（如“pending → confirmed → shipped → delivered”，且要求跳过 confirmed 直接到 delivered 视为异常）不适合堆在单层 SELECT 里用多层 LAG() 和 LEAD() 判断。容易出错，也难调试。
- 第一步 CTE：用
LAG(status) OVER (PARTITION BY order_id ORDER BY event_time)算出prev_status - 第二步 CTE：基于
prev_status和status做基础跃迁标记（is_valid_transition） - 第三步 CTE：用
SUM(CASE WHEN NOT is_valid_transition THEN 1 ELSE 0 END) OVER (...)累计异常次数，用于兜底拦截 - 避免在一层里写
LAG(LAG(status))——SQL Server 2022 CU4 之前有IGNORE NULLSbug，MySQL 8.0 对嵌套偏移支持不稳定
最易被忽略的一点：LAG() 和 SUM() OVER 都依赖 ORDER BY 的确定性。如果 event_time 存在重复值且未用 event_id 等唯一字段兜底，整个状态链的先后关系就不可靠——而这点在测试数据里往往看不出来，上线后数据量一大，时间戳碰撞概率上升，问题才集中爆发。
