LEAD() 更适合“下期对比”类差异报表，因其专为向前取值设计，语义清晰、无需自连接；配合 UNION ALL 与排序序号可实现差异行插入原数据行间，需注意排序稳定性、NULL 处理及跨组边界。
为什么 LEAD() 比 LAG() 更适合做“下期对比”类差异行
报表中常需在当前行下方插入一行“vs 上期”或“vs 下期”的差异计算，比如：本月销售额、下月销售额、差额。此时用 LEAD() 直接取下一行值最自然——它专为“向前看”设计，语义清晰，且避免了自连接或子查询的冗余。
常见错误是误用 LAG() 写成 LAG(sales) OVER (ORDER BY month)，结果算的是“vs 上期”，但差异行要放在当前行之后，逻辑位置反而错位；而 LEAD() 取下值后，可直接与当前行并列展示，对齐直观。
-
LEAD()第二参数默认为 1，即跳过 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 中的兼容性差异
语法基本一致，但 MySQL 对 ORDER BY 子句更敏感：如果窗口定义中 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 != 0，否则除零错误或NULL - 某些 BI 工具（如 Tableau、Superset）对混合类型列敏感，若差异行中
sales列填字符串 “N/A”，而原始行是数值，会导致整个列转为文本型，后续无法求和
实际拼接差异行的最小可行 SQL 框架里，最易出问题的是排序字段的稳定性与 NULL 边界处理——这两处不提前想清楚，上线后数据错位或空值炸裂，远比写错函数名难排查。
