LEAD() 必须在 OVER() 中显式指定 ORDER BY（如 ORDER BY order_time, order_id）才能正确获取下一行时间，否则结果不可靠；计算时间差需手动相减并处理 NULL，且 order_time 列应建索引以避免性能问题。
LEAD() 必须配合 ORDER BY 才能正确取下一行
直接写 LEAD(order_time) 但没指定排序依据，结果完全不可靠——SQL 不保证行物理顺序，LEAD() 默认按查询执行时的“任意顺序”取下一行，不是按时间先后。必须显式用 ORDER BY order_time（或更严谨的 ORDER BY order_time, order_id 防止时间重复）定义逻辑顺序。
常见错误现象：LEAD() 返回 NULL 或乱序时间差，本质是窗口未正确定序。
- 务必在
OVER()子句中写全ORDER BY，不能只依赖外部ORDER BY - 如果
order_time可能重复，加一个唯一列（如order_id）做二级排序，避免非确定性结果 - 不要在子查询外再套一层
ORDER BY试图“修正”，窗口函数的排序必须在OVER()内完成
计算时间间隔要用日期减法，不是直接 LEAD() 减当前值
LEAD(order_time) 只返回下一行的时间值，不自动做减法。需要手动用当前行 order_time 去减它，且注意数据库对时间相减的语法差异。
示例（PostgreSQL / MySQL 8.0+）：
SELECT order_id, order_time, LEAD(order_time) OVER (ORDER BY order_time, order_id) AS next_order_time, LEAD(order_time) OVER (ORDER BY order_time, order_id) - order_time AS time_diff FROM orders;
关键点：
- PostgreSQL 支持直接用
timestamp - timestamp得到interval类型（如1 day 02:30:00） - MySQL 8.0+ 需用
TIMESTAMPDIFF(SECOND, order_time, LEAD(...) )显式指定单位，否则报错 - SQL Server 要用
DATEDIFF(second, order_time, LEAD(...))，且注意LEAD()最后一行返回 NULL，减法结果也是 NULL，无需额外处理
处理 LEAD() 返回 NULL 导致时间差为 NULL 的情况
最后一笔订单没有“下一个订单”，LEAD(order_time) 返回 NULL，导致 time_diff 全为 NULL——这本身是正确行为，但业务上可能需要标记或过滤。
- 用
CASE WHEN LEAD(...) IS NOT NULL THEN ... END包裹计算逻辑，让非末尾行才有值 - 若需统一单位（如全部转成分钟），记得在
CASE内做转换，避免 NULL 参与运算出错 - 别用
COALESCE(LEAD(...), NOW())填充，会扭曲真实间隔；真要补值，应明确业务含义（如“至今未下单”）并单独列字段
性能隐患：ORDER BY 列没索引时 LEAD() 会变慢
LEAD() 本身不触发排序，但 OVER (ORDER BY ...) 要求数据按指定列逻辑有序。如果 order_time 上没索引，数据库必须临时排序整个表，大数据量时 I/O 和内存开销明显。
- 确认执行计划里是否有
Sort操作；若有且表行数 > 10 万，优先建索引 - 复合排序（如
ORDER BY order_time, order_id）建议建联合索引INDEX idx_time_id (order_time, order_id) - 如果只查最近 7 天订单，先用
WHERE order_time >= CURRENT_DATE - INTERVAL '7 days'过滤再开窗，比全表开窗快得多
实际用的时候，最容易被忽略的是排序字段的索引和重复时间值的二级排序——这两点不处理，要么慢得没法接受，要么某天凌晨批量下单时时间差突然错乱。
