LAG()和LEAD()直接按排序确定行间关系，而嵌套查询依赖JOIN条件匹配，若未严格限定时间顺序与唯一约束（如t2.time < t1.time且MAX(t2.time)），易产生多匹配、漏匹配或笛卡尔积，导致时间差计算错误。
直接用 LAG() 或 LEAD() 窗口函数，比嵌套查询更安全、更高效；嵌套查询在时间差计算中极易因关联逻辑错误导致笛卡尔积或漏行。
为什么嵌套查询容易算错时间差
嵌套查询常被用来“找上一笔交易”，但若没严格限定时间顺序和唯一匹配条件，SELECT ... FROM trades t1, trades t2 WHERE t2.time 这类写法会为每笔交易匹配所有更早的记录，产生大量冗余行。尤其当同一用户有多笔交易、或时间戳精度到秒/毫秒时，<code>MAX(t2.time) 子查询又可能因未加 PARTITION BY user_id 而跨用户取值。
用 LAG() 按用户+时间排序取上一行
这是最稳的解法：按用户分组、按时间升序排列，直接取前一行的时间值。不需要关联、不依赖子查询，也不会漏数据。
-
LAG(time) OVER (PARTITION BY user_id ORDER BY time)返回同用户上一笔交易时间 - 与当前行
time相减即可得差值（注意数据库对时间相减的支持：PostgreSQL 返回 interval，MySQL 返回秒数，SQL Server 需用DATEDIFF） - 首次交易的
LAG()结果为NULL，可配合COALESCE或CASE WHEN处理
SELECT id, user_id, time, EXTRACT(EPOCH FROM (time - LAG(time) OVER (PARTITION BY user_id ORDER BY time))) AS diff_seconds FROM trades;
如果必须用嵌套查询，怎么避免常见坑
仅在无法使用窗口函数的老版本 MySQL（
- 子查询必须带
LIMIT 1（MySQL/PostgreSQL）或TOP 1（SQL Server），否则返回多行会报错 -
WHERE条件里要同时约束user_id = t1.user_id和time ，缺一不可 - ORDER BY 必须明确（如
ORDER BY time DESC），否则LIMIT 1结果不确定 - 外部查询需用
LEFT JOIN或COALESCE((SELECT ...), NULL)，否则无上一笔的记录会被过滤掉
SELECT t1.id, t1.user_id, t1.time, EXTRACT(EPOCH FROM (t1.time - t2.time)) AS diff_seconds FROM trades t1 LEFT JOIN LATERAL ( SELECT time FROM trades t2 WHERE t2.user_id = t1.user_id AND t2.time < t1.time ORDER BY t2.time DESC LIMIT 1 ) t2 ON true;
真正麻烦的不是语法，而是时间字段有没有索引、是否含时区、是否允许重复时间戳——这些都会让 LAG() 或子查询行为偏移。上线前务必用真实数据集验证边界 case：比如同一秒内两笔交易、用户只有一笔记录、时间字段为 TIMESTAMP WITHOUT TIME ZONE 却存了 UTC 值却按本地时区解析。
