LEAD函数通过LEAD(status) OVER (PARTITION BY user_id ORDER BY created_at)获取下一行状态值，再用CASE WHEN status <> LEAD(status) THEN 1 ELSE 0 END显式比对；需防NULL干扰，推荐COALESCE(status, '__MISSING__') <> COALESCE(LEAD(status), '__MISSING__')。
LEAD怎么拿到下一条的值并做状态比对？
直接用 LEAD() 提取下一行字段，再和当前行做 = 或 <> 判断就行——它不负责“判断”，只负责把下一行的值拽过来，剩下的逻辑你写在 CASE WHEN 里。
常见错误是试图让 LEAD(status) 自己返回“变化了/没变化”，但它只返回值，比如 'active' 或 'inactive'。你要显式写比较逻辑：
-
LEAD(status) OVER (PARTITION BY user_id ORDER BY created_at)拿到下一条状态 - 再用
CASE WHEN status <> LEAD(status) OVER (...) THEN 1 ELSE 0 END标记是否变化 - 注意：如果
status是 NULL，<>比较会得 NULL，不是 false，得用IS DISTINCT FROM（PostgreSQL）或COALESCE(status, '') <> COALESCE(LEAD(status), '')（兼容写法）
为什么LEAD结果总是NULL，导致状态比对失效？
不是函数坏了，而是语义上“没有下一条”——最后一行、分组内仅一行、WHERE 过滤后排序被破坏，都会让 LEAD() 返回 NULL，进而让 status <> NULL 全为 NULL。
典型场景和应对方式：
- 分区后某用户只有 1 条记录 →
PARTITION BY user_id下所有LEAD()都是 NULL → 加CASE WHEN LEAD(status) IS NOT NULL THEN ... ELSE 'no_next' END -
WHERE created_at > '2026-01-01'写在外层 → 排序基于全表，但过滤后“下一条”可能被删掉 → 把过滤条件提前到 CTE 或子查询中，确保OVER窗口看到的是最终参与排序的数据集 -
ORDER BY created_at有重复值且没加二级排序 → 数据库任意选一行当“下一条”，状态变化标记不稳定 → 改成ORDER BY created_at, id
LEAD配合状态变化做区间划分时容易漏什么？
比如想标记“从 inactive 切到 active 的起始行”，光靠 LEAD() 不够，还得结合 LAG() 或当前行条件，否则边界识别不准。
正确做法是同时看“前状态”和“后状态”：
- 只用
LEAD(status)只能知道“下一条是什么”，但不知道“当前是不是切换点” - 真正要捕获切换，得组合：
CASE WHEN status = 'inactive' AND LEAD(status) = 'active' THEN 'start_active' END - 如果状态字段含 NULL，
= 'active'会跳过 NULL 行；需要明确处理：status IS NOT DISTINCT FROM 'inactive' AND LEAD(status) IS NOT DISTINCT FROM 'active' - 跨多状态（如 pending → processing → done）时，偏移量别硬写
LEAD(status, 2)去“跳过中间态”，应逐行判断，避免漏掉中间状态变更
不同数据库对NULL状态比较的兼容性差异
status <> LEAD(status) 在 MySQL 和 SQL Server 中对 NULL 的行为一致（结果为 NULL），但在 PostgreSQL 中，IS DISTINCT FROM 才能正确把 NULL <> 'active' 判为 true。
安全写法建议统一用：
-
COALESCE(status, '__MISSING__') <> COALESCE(LEAD(status), '__MISSING__')—— 适用于所有主流数据库 - 避免依赖
IGNORE NULLS（SQL Server 2022+ 才修复 bug，且仅影响LEAD查找非 NULL 值的行为，不改变比较逻辑） - 如果业务允许，默认值设成占位符更可控：
LEAD(status, 1, 'unknown') OVER (...)，后续比较就不用总防 NULL
