如何用SQL在报表中增加差异对比行：LEAD函数技巧
为什么 LEAD() 比 LAG() 更适合做“下期对比”类差异行
做报表时，经常遇到一个需求：要在当前数据行下面，额外加一行来展示“与下期对比”的差异。比如，本月销售额是多少，下个月又是多少，两者差额有多大。这时候，用 LEAD() 函数来获取下一行的值，是最直接、最符合直觉的做法——它本来就是为“向前看”而设计的，语义清晰，也省去了自连接或子查询那些繁琐的操作。
一个常见的误区是误用了 LAG()。你可能会写成 LAG(sales) OVER (ORDER BY month)，结果算出来的是“与上期对比”。但问题是，差异行通常需要放在当前行之后展示，逻辑上就错位了。而用 LEAD() 取下期值，然后和当期值并列计算，整个逻辑就顺了，展示起来也直观。
LEAD()的第二个参数默认是1，也就是取下一行的值；如果想对比“下下期”，明确写成LEAD(sales, 2)就行。- 窗口函数里的排序字段（
ORDER BY）必须确保唯一性，或者有稳定的排序依据。否则，如果同一个月有多条记录，LEAD()取到的“下一行”可能就不确定了。 - 对于最后一行数据，
LEAD()会返回NULL。处理差异列时，记得用COALESCE(LEAD(...) - current, 0)给个默认值，或者明确标注为“N/A”。
如何让差异行真正“插入”在原数据行之间（而非追加在末尾）
光在 SELECT 语句里用 LEAD()，只是在原数据旁边多了一列，并没有新增一行。要想实现视觉上“每行原始数据后面紧跟一行差异数据”的效果，就得借助 UNION ALL 把两部分数据拼接起来，并通过排序字段来控制最终的出现顺序。
这里的关键技巧，其实不在窗口函数本身，而在于构造一个带有序号的中间结构：给原始数据行标记 sort_order = 1，给计算出的差异行标记 sort_order = 2。最后按 month, sort_order 排序，数据自然就交替出现了。
- 原始行的所有字段都保留，差异行则只填充必要的字段（比如
month、type = 'vs_next'、sales_diff），其他字段用NULL或占位符填充。 - 使用
UNION ALL时，前后两部分查询的字段数量、数据类型必须严格一致。建议显式写出所有列名，避免隐式类型转换带来的意外错误。 - 如果报表需要分组（比如按地区），那么
LEAD()函数里的PARTITION BY子句，必须和最终结果的ORDER BY逻辑对齐，否则很容易出现跨组取值的混乱。
LEAD() 在 MySQL 8.0+ 和 PostgreSQL 中的兼容性差异
两个数据库的 LEAD() 基本语法一致，但细节上有些“脾气”不同。比如，MySQL 对 ORDER BY 子句更敏感：如果排序字段存在重复值，MySQL 可能会非确定性地选择“下一行”，而 PostgreSQL 则会按物理顺序来（即便如此，也不建议依赖这种行为）。
- MySQL 8.0 及以上版本支持完整的
LEAD(expr, offset, default)参数；如果是 5.7 及以下版本，则不支持窗口函数，只能用自连接来模拟，性能差且容易出错。 - PostgreSQL 允许在
LEAD()里使用更复杂的表达式（比如LEAD(sales * 1.0)），而 MySQL 通常要求第一个参数是纯粹的列引用或简单表达式。 - 两者都要求
OVER子句是完整的，漏写ORDER BY都会导致报错，不能省略。
真实报表场景中容易被忽略的 NULL 处理细节
差异行一旦碰上 NULL 值，整个计算就可能出问题。比如直接做减法或除法，结果会变成 NULL，但业务上可能希望显示为 “-”、“0” 或 “N/A”。这个处理逻辑不应该丢给前端或报表工具，在 SQL 层就应该把语义定义清楚。
- 不要直接写
LEAD(sales) - sales。更稳妥的写法是COALESCE(LEAD(sales), 0) - COALESCE(sales, 0)，这样即使某一方是NULL，结果也不会是NULL。 - 计算百分比差异时（比如
(LEAD(sales) - sales) / sales），必须判断分母sales是否为零，否则会引发除零错误或得到NULL。 - 有些 BI 工具（如 Tableau、Superset）对列的数据类型很敏感。如果差异行里把
sales列填成了字符串 “N/A”，而原始行是数值，整个列可能会被转换成文本类型，导致后续无法进行求和等数值运算。
说到底，在拼接差异行的最小可行 SQL 框架里，最容易出问题的就两件事：排序字段的稳定性，以及 NULL 值的边界处理。这两点如果不在动手前就想清楚，等上线后才发现数据错位或空值泛滥，排查起来的难度可比写错一个函数名要大得多。
