LEAD和LAG函数必须配合ORDER BY及PARTITION BY使用，否则结果不可靠；需用ORDER BY created_at, id保证顺序唯一性，通过子查询或CTE比较当前与前一状态判断变更，并用COALESCE处理LEAD的NULL边界。
LEAD 和 LAG 函数必须配合 ORDER BY 使用，否则结果不可靠
这两个窗口函数依赖明确的行序，如果 ORDER BY 缺失或逻辑错误（比如只按时间排序但未考虑同一秒内多条记录），LEAD() 和 LAG() 会返回任意相邻行，导致状态变更方向错乱。工单场景中，常见错误是仅对 created_at 排序，却忽略同一时间点可能有多个状态写入（如自动触发+人工更新）。务必加上唯一性保底，例如：ORDER BY created_at, id。
用 LAG 获取前一状态，判断是否发生变更
核心思路是：把当前行的状态和上一行的状态做比较。只有两者不同时，才认为发生了有效变更。注意不能直接 WHERE status != LAG(status) —— 窗口函数不能在 WHERE 中使用，得用子查询或 CTE 包一层。
典型写法：
SELECT ticket_id, status, created_at,
LAG(status) OVER (PARTITION BY ticket_id ORDER BY created_at, id) AS prev_status
FROM ticket_events
后续再在外层过滤：WHERE status != prev_status OR prev_status IS NULL（保留首条记录）。
LEAD 可用于预判下一次变更时间，但需小心 NULL 边界
比如计算某次状态停留时长，需要知道下一次变更时间。这时用 LEAD(created_at) 得到“下次变更时刻”，再减去当前 created_at。问题在于最后一条记录的 LEAD() 必然为 NULL，若不做处理，整列计算会变 NULL。
建议统一用 COALESCE() 填充默认值：
-
LEAD(created_at) OVER (PARTITION BY ticket_id ORDER BY created_at, id)→ 下次变更时间 -
COALESCE(LEAD(created_at) OVER (...), NOW())→ 最后一条视为“持续到现在” - 再计算时长：
COALESCE(LEAD(created_at) OVER (...), NOW()) - created_at
分区键（PARTITION BY）漏写会导致跨工单混算
这是最隐蔽也最致命的错误。如果只写 ORDER BY created_at 而忘了 PARTITION BY ticket_id，数据库会把所有工单事件拉成一个大序列，LAG(status) 可能取到另一个工单的上一条状态，结果完全失真。
验证方法很简单：查几个 ticket_id 的样本，看 prev_status 是否总来自同一个工单。只要出现跨 ID 的值，就是分区写漏了。
另外注意：某些旧版 MySQL（LAG/LEAD。
