用LAG()或LEAD()替代关联子查询更合理：前者专为计算前后行时间差设计，可读性强、性能优；后者易致全表扫描、延迟升高。
用LAG()或LEAD()替代关联子查询更合理
直接写关联子查询计算前后行时间差，不仅可读性差、性能低，而且在多数主流数据库（PostgreSQL、SQL Server、Oracle、MySQL 8.0+）中完全没必要——LAG() 和 LEAD() 窗口函数就是为此设计的。强行用自连接或相关子查询，容易触发全表扫描，尤其在没索引的 order by 字段上，延迟会明显上升。
典型错误写法：(SELECT t2.event_time FROM logs t2 WHERE t2.id —— 这类子查询在每行都执行一次，无索引时是 O(n²) 复杂度。
正确做法是先确保排序字段有索引（如 CREATE INDEX idx_logs_event_time ON logs(event_time);），再用窗口函数：
SELECT id, event_time, EXTRACT(EPOCH FROM (event_time - LAG(event_time) OVER (ORDER BY event_time))) AS sec_since_prev FROM logs;
当必须用关联子查询时，如何避免性能崩盘
某些旧版数据库（如 MySQL 5.7）不支持窗口函数，这时才考虑关联子查询。但必须满足三个条件，否则查询可能卡死：
-
ORDER BY字段必须有索引，且子查询里WHERE条件能命中该索引最左前缀 - 子查询必须带
LIMIT 1，且ORDER BY与外层一致（否则优化器无法下推） - 避免在子查询中使用函数包裹字段，例如
DATE(event_time)会让索引失效
安全示例（假设 id 为主键且递增）：
SELECT t1.id, t1.event_time,
EXTRACT(EPOCH FROM (t1.event_time - (
SELECT t2.event_time
FROM logs t2
WHERE t2.id < t1.id
ORDER BY t2.id DESC
LIMIT 1
))) AS sec_since_prev
FROM logs t1;处理NULL和边界行的常见陷阱
LAG() 对首行返回 NULL，LEAD() 对末行同理。直接参与时间运算会导致整列变 NULL，不是数据缺失，而是表达式结果为 NULL。
不要这样写：event_time - LAG(event_time) OVER (...) —— 首行结果是 NULL，但你可能需要 0 或默认值。
推荐写法：
- 用
COALESCE(LAG(event_time) OVER (...), event_time)填充首行为自身时间（差值为 0） - 用
NULLIF(event_time - LAG(event_time) OVER (...), INTERVAL '0' SECOND)过滤掉重复时间点 - 若需排除首行，加
WHERE LAG(event_time) OVER (...) IS NOT NULL
跨分组计算（如按用户分组求每次操作间隔）
误以为加个 GROUP BY user_id 就能分组算间隔——不行。LAG() 必须配合 PARTITION BY，不是 GROUP BY。
错误：GROUP BY user_id, event_time + LAG() → 窗口被破坏，结果错乱。
正确写法：
SELECT
user_id,
event_time,
EXTRACT(EPOCH FROM (
event_time - LAG(event_time) OVER (
PARTITION BY user_id ORDER BY event_time
)
)) AS sec_since_last
FROM user_events;注意：PARTITION BY 字段也应建索引，例如 CREATE INDEX idx_user_events ON user_events(user_id, event_time);，否则分区内部排序成本高。
真正难的不是语法，是想清楚“前后行”到底按什么逻辑定义：是全局顺序？还是每个用户的独立序列？一旦 PARTITION BY 漏写或写错字段，差值就全乱了，而且不容易肉眼发现。
