SQL时间差计算实战：避开LEAD与DATEDIFF的四大陷阱
LEAD 函数怎么写才能拿到下一行的时间
直接写个LEAD()就指望它工作？事情可没这么简单。这个函数默认确实返回下一行的值，但有个关键前提：你必须通过ORDER BY明确告诉它排序规则，否则结果的顺序完全是不可预测的。而在分组计算场景下，PARTITION BY更是灵魂所在——少了它，整个表会被当作一个巨大的分组来处理，结果就是张三的结束时间可能错误地关联到了李四的开始时间，数据彻底乱套。
所以，正确的公式必须同时锁定分组和顺序：
LEAD(event_time) OVER (PARTITION BYuser_idORDER BYevent_time)
这里还有个细节值得敲黑板：event_time字段的类型必须是DATETIME这类时间类型。如果它存的是字符串格式（比如'2024-03-15 10:22:30'），LEAD()本身可能不会报错，但等到下一步用DATEDIFF()计算差值时，系统就会直接“罢工”。稳妥起见，先用CONVERT()或CAST()转换一下类型。
DATEDIFF 计算时间差时单位选错会怎样
DATEDIFF()的第一个参数——时间单位，可不是随便选选就行的装饰品。它直接决定了计算结果的精度和业务意义。举个例子，如果你想分析用户秒级的活跃行为，却错误地使用了MINUTE作为单位，那么59秒的间隔就会被算成0分钟，大量高频的短间隔操作就这样在数据层面“被消失”了。
如何选择合适的时间单位？可以参考下面这个按精度排列的优先级清单：
SECOND：适用于操作日志、实时监控、API调用跟踪等需要秒级精度的场景。MILLISECOND：精度最高，但要注意这是SQL Server的专属选项，且计算跨度超过24天可能会溢出报错。MINUTE：适合分析页面停留时长、登录会话间隔等对分钟变化敏感的场景。HOUR：使用时要格外谨慎，因为它会抹平大量细节（比如1小时59分和1小时01分，结果都是1小时）。
一个完整的计算示例如下：
DATEDIFF(SECOND,event_time, LEAD(event_time) OVER (PARTITION BYuser_idORDER BYevent_time))
NULL 值怎么处理才不影响分组统计
这是使用LEAD()时必然会遇到的“经典问题”：每个分组内的最后一行，没有“下一行”了，所以LEAD()会老老实实地返回NULL。如果把这个NULL直接塞进DATEDIFF()，那么整个计算结果列都会变成NULL。这并非系统故障，而是标准设计。但问题在于，大多数报表工具和后续的数据应用，根本无法处理一整列都是NULL的情况。
通常有两种务实的选择来应对：
- 使用
ISNULL()或COALESCE()函数，将NULL替换为一个默认值（比如0或-1）。例如：ISNULL(DATEDIFF(SECOND, ..., LEAD(...)), 0)。 - 在查询的最外层用
WHERE子句直接过滤掉这些末尾行：WHERE LEAD(...) IS NOT NULL。这种方法得到的数据集更干净，避免了因填充0而扭曲平均间隔时间的计算。
需要特别提醒的是，试图通过判断原始时间字段是否为NOT NULL来解决这个问题是徒劳的，因为这完全搞错了NULL值的来源——它来自LEAD()函数本身，而非原始数据。
性能瓶颈往往卡在排序和索引上
别忘了，LEAD()这类窗口函数的背后，是大量的数据排序操作。当面对千万级甚至更大的事件表时，如果没有合适的索引，每次查询都可能触发一次全表扫描和临时排序，查询时间从毫秒级暴跌到几十秒都不是新鲜事。
针对“按用户分组，按时间排序”这个典型模式，下面这个复合索引是性能的救星：
CREATE INDEX idx_user_time ONevents(user_id,event_time)
字段的顺序至关重要：user_id在前，数据库才能高效地进行分组；event_time在后，则支撑了组内快速排序。如果业务查询经常还需要按event_type过滤，可以考虑将其加入索引，变成(user_id, event_type, event_time)。但切记，索引不是越宽越好，额外的字段会增加索引维护的成本。
另外，对于使用SQL Server 2016及以上版本的用户，LEAD()函数支持第三个参数，可以指定一个默认值来代替NULL（例如LEAD(event_time, 1, '9999-12-31')...），这有时能省去一次ISNULL调用。不过，除非团队非常熟悉该语法，否则为了代码的清晰易懂，显式处理NULL仍然是更推荐的做法。
