<p>能用DATEDIFF或EXTRACT计算时间差，但必须按数据库类型选择对应函数并嵌入窗口内：PostgreSQL用EXTRACT(EPOCH FROM (t - LAG(t)))，MySQL用TIMESTAMPDIFF单位参数，SQL Server用DATEDIFF且注意单位精度；必须在SELECT中直接计算，不可放OVER外，且需确保时间字段为正确类型并建立(user_id, event_time)联合索引。</p>
窗口函数里不能直接用 DATEDIFF 或 EXTRACT 计算时间差？
不是不能，而是得看数据库类型和时间字段类型。PostgreSQL 用 EXTRACT(EPOCH FROM ...) 转秒数再相减最稳；MySQL 8.0+ 支持 TIMESTAMPDIFF，但必须写在窗口函数内部而非外部；SQL Server 的 DATEDIFF 可以直接嵌套，但单位参数（如 SECOND、MILLISECOND）选错会导致精度丢失。
常见错误是把时间差计算放在 OVER() 外面——窗口函数只负责分组排序，不参与运算逻辑。时间差必须作为表达式的一部分出现在 SELECT 或 ORDER BY 中。
按用户分组，算相邻两条记录的时间间隔怎么写？
核心是用 LAG() 拿上一行时间，再跟当前行相减。注意三点：
-
LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time)必须指定PARTITION BY和ORDER BY，否则跨用户混算 - PostgreSQL 示例：
EXTRACT(EPOCH FROM (event_time - LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time))) AS sec_diff - MySQL 示例：
TIMESTAMPDIFF(SECOND, LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time), event_time) AS sec_diff - 如果
event_time是STRING类型（如'2023-01-01 10:00:00'），先用STR_TO_DATE()或TO_TIMESTAMP()转成时间类型，否则相减报错
为什么 LEAD() 减 LAG() 会出 NULL 或负数？
因为 LAG() 返回前一行值，LEAD() 返回后一行值，两者不在同一行——强行相减等于拿不同行的数据做运算，语义错乱。正确做法是只用其中一个（通常是 LAG()）和当前行对比。
容易踩的坑：
- 没处理首行的
LAG()返回NULL：加COALESCE(LAG(...), event_time)或用CASE WHEN过滤 - 时间字段含时区（如
TIMESTAMPTZ）：PostgreSQL 中不同行时区不一致会导致差值异常，建议统一转为UTC后再算 - 窗口定义漏了
ORDER BY：结果顺序不可控，差值毫无意义
性能差到查不动？检查这几个地方
时间差计算本身不重，慢通常是因为窗口函数没走索引。关键点：
- 确保
PARTITION BY和ORDER BY字段上有联合索引，例如(user_id, event_time) - 避免在
LAG()里套复杂表达式（如DATE(event_time)），会阻止索引使用 - 如果只想要“最近一次操作距现在多久”，别用窗口函数，改用子查询或
MAX()聚合更高效 - BigQuery 等引擎对
EXTRACT+ 窗口组合优化较差，可先用ARRAY_AGG预聚合时间序列再计算
时间类型和窗口函数的交互细节多，光记语法不够，得结合具体引擎的执行计划看实际是否走索引。
