nth_value返回null主因是默认窗口帧为range between unbounded preceding and current row，仅覆盖当前行及之前，无法取后续位置的值；显式指定rows between unbounded preceding and unbounded following并确保分组行数≥n可避免该问题。
为什么NTH_VALUE返回NULL而不是想要的值
多数人用 NTH_VALUE 时第一反应是“怎么全是NULL”，根本原因是它默认使用 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 窗口帧——也就是说，只看当前行及之前的数据。如果目标值在当前行之后（比如要取第3条，但当前才处理到第1行），就拿不到。
- 必须显式指定窗口帧为
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，否则无法访问分组内后续行 - 不同数据库对默认帧的处理略有差异：PostgreSQL 和 Oracle 默认就是
RANGE帧；MySQL 8.0+ 虽支持NTH_VALUE，但也遵循同样规则 - 即使指定了完整帧，若分组实际行数少于N（比如要取第5条但只有3条），仍返回NULL——这不是bug，是设计行为
如何安全获取分组内第N条且避免NULL陷阱
直接写 NTH_VALUE(col, 3) 很危险，尤其当数据不规整时。更稳妥的做法是先用 ROW_NUMBER() 标记序号，再用条件聚合提取：
SELECT
group_id,
MAX(CASE WHEN rn = 3 THEN value END) AS third_value
FROM (
SELECT
group_id,
value,
ROW_NUMBER() OVER (PARTITION BY group_id ORDER BY sort_col) AS rn
FROM t
) t2
GROUP BY group_id;
-
ROW_NUMBER()稳定可控，不会因重复排序值产生歧义 - 用
MAX(CASE ...)替代NTH_VALUE，避免窗口帧理解偏差带来的NULL - 如果需要保留原始行结构（而非聚合后一行），可在子查询中加
JOIN或用LEFT JOIN关联序号表
NTH_VALUE和LAG/LEAD的本质区别在哪
NTH_VALUE 不是偏移函数，它不依赖“相对位置”，而是基于整个窗口内的绝对序号定位。而 LAG(col, 2) 永远取“往前两行”的值，与分组长度无关。
-
LAG(col, N)只能取前N行，不能跨到后N行；NTH_VALUE(col, N)可以取任意序号（前提是窗口帧覆盖该位置） - 当排序字段有重复值时，
NTH_VALUE的结果可能不稳定（取决于数据库的相等排序处理方式），ROW_NUMBER()+ 显式ORDER BY子句才能保证确定性 - 性能上，
NTH_VALUE需要完整扫描窗口范围；LAG/LEAD通常只需维护固定大小滑动窗口，更轻量
MySQL 8.0+使用NTH_VALUE的特别注意点
MySQL 对 NTH_VALUE 支持较晚，且存在两个容易忽略的限制：
- 不支持
DISTINCT参数，即NTH_VALUE(DISTINCT col, n)会报错 - 排序字段若含NULL，默认排在最前（
NULLS FIRST），但MySQL不支持显式控制NULL位置，可能导致第N条意外命中NULL值 - 必须搭配
OVER子句中的PARTITION BY和ORDER BY，缺一不可；只写ORDER BY不分区，相当于全表一个组
真正麻烦的不是语法，而是调试时看不到窗口帧的实际边界——建议先用 COUNT(*) OVER (PARTITION BY ...) 查每组行数，再确认N是否合法。
