LAG函数需配合OVER(ORDER BY payment_time)才能正确获取上一条订单支付时间，否则结果随机或报错；计算等待时长须按数据库类型用TIMESTAMPDIFF、EXTRACT(EPOCH FROM ...)等适配写法，并预过滤测试单、异常时间及跨用户干扰。
LAG函数怎么获取上一条订单的支付时间
直接用 LAG(payment_time) 就能拿到前一行的支付时间，但必须配合 ORDER BY order_id 或 ORDER BY created_at —— 否则“上一条”是随机的。常见错误是只写 LAG(payment_time) 却没加 OVER 子句，会报错 Window function requires OVER clause。
实际场景中，订单不一定按创建顺序支付，所以更稳妥的是按 payment_time 排序（前提是该字段非 NULL）：
SELECT order_id, payment_time, LAG(payment_time) OVER (ORDER BY payment_time) AS prev_payment_time FROM orders WHERE payment_time IS NOT NULL;
计算等待时长要注意时区和数据类型
MySQL、PostgreSQL、SQL Server 对时间相减返回的类型不同：MySQL 返回秒数（TIMESTAMPDIFF(SECOND, ...) 更可控），PostgreSQL 直接返回 interval，而 SQL Server 需用 DATEDIFF(second, ...)。别直接用 payment_time - LAG(...)，在 MySQL 里会得到意外整数，在 PostgreSQL 可能报错类型不匹配。
推荐写法（以 PostgreSQL 为例）：
SELECT order_id, payment_time, LAG(payment_time) OVER (ORDER BY payment_time) AS prev_payment_time, EXTRACT(EPOCH FROM (payment_time - LAG(payment_time) OVER (ORDER BY payment_time))) AS wait_seconds FROM orders WHERE payment_time IS NOT NULL;
- 如果用 MySQL，替换为
TIMESTAMPDIFF(SECOND, LAG(payment_time) OVER (ORDER BY payment_time), payment_time) - 如果字段含时区（如
timestamptz），确保前后时区一致，否则差值可能偏移 1 小时 - NULL 等待时长通常出现在第一条记录，这是正常行为，不是 bug
如何排除测试订单或异常支付时间
真实数据里常混着测试单（order_id LIKE 'TEST%'）、退款重付单（同一用户短时间内多次支付）、甚至未来时间（系统时钟错误）。这些会让 LAG 算出负数或极大值，污染等待时长统计。
建议在 WHERE 中预过滤，并用窗口内条件限制：
- 先剔除测试数据：
WHERE order_id NOT LIKE 'TEST%' AND status = 'paid' - 再用
CASE WHEN屏蔽异常差值：CASE WHEN wait_seconds BETWEEN 0 AND 86400 THEN wait_seconds END（限定 1 天内） - 若需按用户分组看等待时长（比如用户 A 第二次支付比第一次晚多久），得加
PARTITION BY user_id，否则跨用户比较无意义
性能差？可能是没建好索引
LAG 本身不慢，但排序成本高。如果 ORDER BY payment_time 涉及千万级数据且无索引，查询可能卡住。别指望加个 LIMIT 100 就能提速——窗口函数会在 LIMIT 前完成全量排序。
优化手段很实际：
- 在
payment_time字段建 B-tree 索引（MySQL/PostgreSQL 都适用） - 如果只查最近 7 天，务必加上时间范围过滤：
AND payment_time >= NOW() - INTERVAL '7 days'，让索引生效 - 避免在
LAG的OVER子句里用表达式，比如ORDER BY DATE(payment_time)，会导致索引失效
真正容易被忽略的是：等待时长这个指标，天然依赖「支付事件的时序完整性」。如果支付成功消息延迟上报、或补偿任务重放了旧记录，LAG 算出来的就不是真实等待，而是数据链路延迟。这时候得结合日志时间戳对齐，而不是只信数据库字段。
