在日常SQL性能优化实践中，常被问及一个经典难题：想要获取某条记录的后续行数据，究竟是使用自连接更优，还是借助LEAD()窗口函数更合适？今天就从性能、健壮性和时序稳定性三个维度，深入剖析这个问题。
先给出几个关键结论：LEAD()只需执行一次排序并通过线性扫描即可完成，时间复杂度为O(n log n)；而自连接每行都要重新触发关联运算，当数据量增大时，性能随数据量呈指数级退化至O(n²)。更重要的是，LEAD()不依赖物理ID的连续性，支持默认值参数避免NULL污染，并且强制要求指定ORDER BY子句来保证逻辑顺序的稳定——这些优势自连接通常难以同时实现。
LEAD() 避免重复扫描，自连接却逐行重查
自连接查询“下一行”的常见写法，通常为JOIN t a ON a.id = b.id + 1或JOIN t a ON a.time = b.time + INTERVAL '1 day'。问题何在？数据库引擎对主表的每一行都需重新执行关联操作，若匹配条件未能利用索引，就会触发全表扫描——10万行规模的表可能导致高达100亿行的扫描量。性能差距由此拉开。
LEAD()的执行策略截然不同：仅执行一次排序操作（按ORDER BY字段），随后线性扫描所有数据，从内存缓冲区中直接获取相邻行的值。时间复杂度从O(n²)降至O(n log n)，数据规模越大，性能差异越显著。
- 自连接的性能危险信号：
EXPLAIN中Type: ALL、Rows列数值急剧膨胀、存在DEPENDENT SUBQUERY。 LEAD()的执行计划里，通常仅出现Using filesort（仅当ORDER BY字段无索引时）或者直接Index Scan。- 若业务场景允许，优先在
WHERE条件中过滤数据后再应用窗口函数——比如只查最近30天的数据——可显著降低排序开销。
LEAD() 不依赖物理ID的连续特性，防止匹配失败
生产环境下id字段几乎不可能连续：记录删除、批量数据导入、分库分表策略、UUID主键等情况，任何一种都会导致a.id = b.id + 1这种写法返回空值或错误匹配。这种情况并非罕见，而是常态。
LEAD(value) OVER (PARTITION BY user_id ORDER BY event_time, id)严格遵循ORDER BY指定的逻辑顺序，与存储的物理位置无关。只要排序字段组合具有唯一性——比如加上id作为二级排序——查询结果便是可复现的。
- 一个典型错误用法：
LEAD(value) OVER (ORDER BY event_time)——当event_time重复时，MySQL 8.0每次执行的返回结果可能不一致。 - 正确的做法应当显式补充唯一性字段，如
ORDER BY event_time, id或ORDER BY event_time, created_at。 - 在MySQL中，若
event_time包含NULL，默认排序会将NULL值置于最前，此时首行记录的LEAD()可能无法获取有效值；可通过IFNULL(event_time, '1970-01-01')预先处理。
LEAD() 默认值参数可有效避免NULL污染，自连接无法实现
自连接在遇到“无后续行”的场景时，只能借助LEFT JOIN返回NULL值。后续的差值、增长率等计算将直接因NULL而失效，还需额外嵌套COALESCE()进行空值处理。代码冗长且易维护性差。
LEAD(value, 1, 0)的第三个参数即为默认值：当处理最后一行时直接返回0，无需额外的空值判断。
- 一个常见应用场景：计算环比增长，当分母可能为0时使用
NULLIF(amount, 0)，分子用LEAD(amount, 1, 0)，整个计算表达式不会报错。 - 需注意：MySQL 8.0不支持
LEAD(value, 1) DEFAULT 0这种语法，必须写成LEAD(value, 1, 0)。 - 若默认值需要动态生成——比如取当前组的平均值——则需要通过子查询或CTE预先计算出再作为参数传入，
LEAD()函数目前不支持直接使用表达式作为默认值。
ORDER BY 是 LEAD() 的强制要求，遗漏即报错
LEAD()必须与ORDER BY子句一起使用，否则MySQL将抛出错误：ERROR 3589 (HY000): Window '。这不是可选的，而是语法规定的强制要求。
- 错误示例：
LEAD(amount) OVER (PARTITION BY region)——此写法会触发错误。 - 正确写法：
LEAD(amount) OVER (PARTITION BY region ORDER BY ym)。 - 若
ym字段为字符串类型（比如'2024-01'），需确保字典序与时间顺序一致；否则应先用STR_TO_DATE(ym, '%Y-%m')转换为日期后再排序。 PARTITION BY子句可以省略，但一旦使用了分区子句，ORDER BY仍然必须存在；未分区时，ORDER BY则作用于整个表进行排序。
归根结底，真正制约性能的并非函数名称，而是排序字段是否建有索引、ORDER BY的排序稳定性，以及在WHERE阶段是否已提前过滤掉无效数据。窗口函数虽然高效，但并非万能——要善用它们，关键在于理解其背后的执行逻辑。
