LAG函数返回NULL主因是未显式指定ORDER BY，导致行序不可控；必须用ORDER BY time_col ASC确保时间升序，并配合PARTITION BY user_id分组及COALESCE处理首行NULL。
LAG函数为什么返回NULL而不是上一行时间？
因为LAG()默认按查询结果的物理顺序取值，而SQL不保证行序——除非你显式写ORDER BY。没加排序时，数据库可能按索引扫描顺序、缓存顺序甚至并行线程顺序返回，LAG(time_col)拿到的“上一行”根本不可控，自然常为NULL或错乱值。
实操建议：
- 必须在窗口定义中用
ORDER BY time_col（推荐用ASC，时间升序才符合“前一次”的语义） - 若时间有重复，需补一个唯一排序键，比如
ORDER BY event_time, id，否则相同时间的多行相对顺序不确定 - 避免用
ORDER BY created_at DESC再套LAG()想“看后一行”，逻辑易反——直接用LEAD()更安全
计算时间差时，LAG结果为空导致整个表达式为NULL怎么办？
LAG()对第一行（或分区首行）必然返回NULL，一旦参与减法如event_time - LAG(event_time)，整列就全NULL了——这是最常踩的坑。
实操建议：
- 用
COALESCE(LAG(event_time), event_time)把首行的NULL替换成自身，差值为0；或用COALESCE(LAG(event_time), '1970-01-01'::timestamp)强制非空（注意类型要一致） - 更合理的做法是用
CASE WHEN ROW_NUMBER() OVER (...) = 1 THEN 0 ELSE event_time - LAG(event_time) END，明确区分首行 - PostgreSQL可用
LAG(event_time, 1, event_time) OVER (...)设置默认值；MySQL 8.0+支持第三个参数，但旧版不行
按用户分组计算间隔，但LAG跨用户混算怎么办？
漏写PARTITION BY user_id是高频错误。没分区时，所有用户的时间戳被拉成一长串排序，A用户的最后一次和B用户的第一次强行相减，结果毫无业务意义。
实操建议：
- 只要业务逻辑是“每个用户的独立行为序列”，窗口定义里必须带
PARTITION BY user_id - 分区键要和业务主键对齐：比如订单表按
user_id分，日志表按session_id分，别错用device_id替代 - 分区后若某用户只有一条记录，
LAG()仍返回NULL，需配合上一条的COALESCE或CASE处理
大表上LAG+时间计算慢，怎么优化？
窗口函数本身不走索引，全表扫描+排序是性能瓶颈。尤其当ORDER BY event_time字段未建索引，或数据量超千万时，延迟明显。
实操建议：
- 确保
ORDER BY字段（如event_time）和PARTITION BY字段（如user_id）联合建索引：CREATE INDEX idx_user_time ON events(user_id, event_time) - 避免在窗口函数里嵌套复杂表达式，比如
LAG(EXTRACT(EPOCH FROM event_time))——先在子查询里算好数值型时间戳，再窗口计算 - 如果只关心“是否超过5分钟”，别算精确秒数，用
event_time > LAG(event_time) + INTERVAL '5 minutes'，数据库能更好利用索引范围扫描
真正卡住的往往不是LAG本身，而是没意识到它依赖排序稳定性——时间字段精度、重复值、缺失值，任何一个没对齐，结果就漂移。先理清业务上的“前一次”到底指什么，再决定ORDER BY和PARTITION BY怎么配。
