NTH_VALUE是标准SQL窗口函数，用于获取指定排序下窗口帧中第N个位置的值；但它并非无条件返回第N行——其结果严格依赖显式定义的窗口框架（如ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING），否则默认帧范围（CURRENT ROW及之前）常导致前N-1行返回NULL。
什么是 NTH_VALUE？它真能取窗口里第 N 条记录吗？
NTH_VALUE 是标准 SQL（PostgreSQL、Oracle、SQL Server 2012+、BigQuery 等支持）提供的窗口函数，用于获取当前窗口帧（frame）中按排序后第 N 个位置的表达式值。但它**不是无条件返回“第 N 行”**——它的行为高度依赖 ROWS 或 RANGE 框架定义，且当目标位置超出当前帧范围时，默认返回 NULL（除非显式指定 FROM FIRST/FROM LAST 和 IGNORE NULLS）。
常见误解：以为写 NTH_VALUE(sales, 2) 就一定能拿到排序后第二高的销售额。实际可能拿不到，原因往往出在窗口帧没设对。
必须显式定义窗口框架，否则结果不可靠
绝大多数数据库中，NTH_VALUE 的默认窗口框架是 UNBOUNDED PRECEDING TO CURRENT ROW，也就是说：只看从第一行到当前行这个动态区间。如果当前行是第 1 行，那根本不存在“第 2 行”，NTH_VALUE(col, 2) 必然为 NULL。
解决方法是用 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 把整个分区都纳入帧内：
SELECT
name,
score,
NTH_VALUE(score, 2) OVER (
ORDER BY score DESC
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
) AS second_highest_score
FROM students;
- 不写
ROWS子句 → 默认只看到“当前行及之前”，NTH_VALUE(..., 2)在前两行基本都是NULL -
ROWS BETWEEN ...显式拉满帧范围，才能稳定取到全局第 2 名 - 注意：PostgreSQL 要求必须写
ORDER BY；SQL Server 允许无序但结果不确定
FROM FIRST vs FROM LAST 决定重复值怎么算
当排序字段有重复值（比如多个并列第 1 名），NTH_VALUE 默认使用 FROM FIRST —— 即取排序后物理位置最靠前的那个“第 N 个”。你也可以显式写 FROM LAST 取最后一个匹配项：
SELECT product, price, NTH_VALUE(product, 1) OVER (ORDER BY price DESC FROM LAST) AS most_expensive_last_match FROM items;
- 假设价格前三行为
[100, 100, 95]，NTH_VALUE(product, 1) FROM FIRST返回第一个 100 对应的商品 -
FROM LAST则返回第二个 100 对应的商品（即排序后位置更靠后的那个） - 这个选项只影响“第 N 个”在重复值中的锚定方式，不影响 N 的计数逻辑
和 LAG/LEAD、FIRST_VALUE/LAST_VALUE 的关键区别在哪？
NTH_VALUE 是唯一能直接指定任意正整数位置（如第 3、第 7）的窗口函数；而其他函数能力有限：
-
LAG(col, 2)只能取“往前数第 2 行”，不能跨分区或按排序取；它依赖物理偏移，不是逻辑排名 -
FIRST_VALUE(col)等价于NTH_VALUE(col, 1)，但不支持指定任意 N -
LAST_VALUE(col)默认只看到CURRENT ROW，常需配合ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING才等价于全局末位，不如NTH_VALUE直观可控 - 性能上，
NTH_VALUE需要完整扫描帧内数据来定位第 N 项，大数据量窗口下比LAG/LEAD开销略高
真正容易被忽略的是：很多用户写了 NTH_VALUE 却没检查执行计划里是否触发了帧重排（re-sort），尤其在嵌套窗口或复杂 PARTITION BY 场景下，NTH_VALUE 可能悄悄变成性能瓶颈。
