状态翻转节点是status值与前一行不同的记录位置，LAG()通过取前一行值并天然处理首行NULL来精准识别翻转点，必须配合ORDER BY和必要时PARTITION BY+唯一排序字段使用。
什么是状态翻转节点，为什么 LAG() 是核心工具
状态翻转节点指某条记录的 status 值与前一条（按时间/序号排序）不同时的位置——比如用户从 'active' 变为 'inactive' 的那行。这类问题不能靠 GROUP BY 解决，因为翻转是逐行比较产生的，必须用窗口函数锚定“上一行”。LAG() 是最直接的选择：它能安全取前一行值，且对首行默认返回 NULL，天然适配边界判断。
实操建议：
- 必须搭配
ORDER BY子句（如ORDER BY event_time），否则LAG()顺序无意义 - 不要用
LEAD()反向推导，会把翻转点错位到“变化发生前一行” - 若排序字段有重复（如毫秒级时间相同），需加唯一键（如
id）保序：ORDER BY event_time, id
如何写条件识别翻转行：用 WHERE 过滤还是 CASE 标记
翻转行本身是逻辑结果，不是原始数据列，所以得先用 LAG() 构造出可比较的字段，再过滤。常见错误是试图在 WHERE 中直接调用窗口函数——SQL 不允许，必须嵌套子查询或 CTE。
推荐做法：
- 用 CTE 先算出
prev_status：WITH status_with_prev AS (<br> SELECT *, LAG(status) OVER (ORDER BY event_time) AS prev_status<br> FROM events<br>)
- 外层查
WHERE status != prev_status OR prev_status IS NULL——IS NULL捕获首行（即第一次出现的状态） - 避免写
status != COALESCE(prev_status, '')，空字符串可能和真实status冲突
处理多状态、多分组时，PARTITION BY 怎么加才不出错
当要分别追踪每个用户、设备或订单的状态翻转时，必须按业务主键分区。但容易漏掉一个关键点：**分区字段必须和排序字段一起决定唯一性**。例如按 user_id 分区、按 event_time 排序，若同一用户有多条同时间事件，LAG() 返回哪条不确定。
实操要点：
-
PARTITION BY user_id ORDER BY event_time, event_id——event_id作为决胜排序字段 - 分区字段不能是计算列（如
PARTITION BY SUBSTRING(phone, 1, 3)），部分数据库不支持 - MySQL 8.0+ 和 PostgreSQL 支持，但旧版 MySQL（
性能陷阱：大表上 LAG() 为什么突然变慢
LAG() 本身不慢，但常见拖慢查询的是没建好索引。窗口函数执行前，数据库需先按 ORDER BY（及 PARTITION BY）物理排序数据。若对应字段无索引，就会触发磁盘排序，千万级表可能卡数分钟。
检查和优化方法：
- 用
EXPLAIN看执行计划，确认是否出现Using filesort或Temporary table - 复合索引应覆盖分区+排序字段，如：
CREATE INDEX idx_user_time_id ON events(user_id, event_time, id) - 避免在
LAG()外层再套复杂聚合（如SUM() OVER(...)），多窗口函数叠加会显著增加内存开销
翻转节点提取看似简单，真正上线时最容易栽在排序字段重复、分区键遗漏或索引缺失上——这三个点不提前验证，跑生产数据时才发现超时或结果错乱，就只能回退重写。
