offset不可靠是因为它按物理行偏移，不处理重复薪资的并列排名；例如[100,90,90,80]中第2高应为90，但offset=1可能误取重复值，且第3高逻辑已失效；正确解法是用dense_rank()实现逻辑排名。
为什么 OFFSET 不能可靠解决“第N个最高薪资”
当存在重复薪资时，OFFSET + LIMIT 会跳过固定行数，而非逻辑上的“第N高”。比如薪资为 [100, 90, 90, 80]，求第2高——真实答案应是 90，但 ORDER BY salary DESC OFFSET 1 LIMIT 1 返回的仍是 90；而求第3高时，它返回 80（错误，正确应为 80），看似碰巧对了，但逻辑已崩坏。本质是 OFFSET 按物理行偏移，不感知并列排名。
实操建议：
- 永远避免用
OFFSET解“第N高/低”类问题，除非明确要求“跳过前N-1行取下一行”，且业务接受并列值被拆散 - 若表无主键或排序字段不唯一，
OFFSET结果本身就不稳定（不同执行可能返回不同行） - 分页场景可用
OFFSET，但排名类需求必须换思路
DENSE_RANK() 是最贴合“第N个最高薪资”的窗口函数
DENSE_RANK() 对相同薪资赋予相同名次，且不跳过后续名次：薪资 [100, 90, 90, 80] → 排名 [1, 2, 2, 3]。这样查 WHERE rnk = N 就能精准命中所有第N高薪资记录。
示例（MySQL 8.0+/PostgreSQL）：
SELECT DISTINCT salary FROM ( SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk FROM Employee ) t WHERE rnk = 2;
注意点：
- 必须用
DISTINCT或外层去重，否则相同薪资的多条记录都会返回 - 不能用
RANK()：它会跳名次（[100,90,90,80]→[1,2,2,4]），导致第3高查不到 - 不能用
ROW_NUMBER()：它强制唯一编号（[1,2,3,4]），完全无视并列，违背题意
性能差异：窗口函数 vs 子查询模拟
在小表（DENSE_RANK() 和相关子查询（如 (SELECT COUNT(DISTINCT e2.salary) FROM Employee e2 WHERE e2.salary >= e1.salary) = N）速度接近；但大表上窗口函数通常快 3–10 倍，因只需一次排序 + 扫描，而子查询是 N² 级嵌套扫描。
关键限制：
- MySQL 5.7 及更早版本不支持窗口函数，必须用子查询或变量模拟（但变量顺序不可靠，不推荐）
- PostgreSQL 和 SQL Server 对
DENSE_RANK()优化成熟；Oracle 同样高效 - 如果 N 很大（如“第1000高”），窗口函数仍需全排序，此时可考虑加
salary索引 +LIMIT预剪枝（但会再次引入并列歧义，慎用）
面试时最容易被追问的边界情况
面试官常卡在“N 超出实际排名范围”或“全员薪资相同时”的处理。这些不是语法问题，而是需求理解漏洞。
应对方式：
- 先确认 N 是否保证有效：若未说明，应主动问“N 是否恒在有效范围内？”——否则
DENSE_RANK() = N可能返回空集 - 全员同薪时，
DENSE_RANK()全为 1，所以只有 N=1 有结果，N>1 返回空——这是正确行为，无需额外补COALESCE - 如果题目隐含“必须返回一行”，才需要加
COALESCE((SELECT ...), NULL)或用LEFT JOIN配合VALUES (N)做兜底
真正容易被忽略的是：窗口函数的 ORDER BY 必须明确指定 NULLS LAST 或 NULLS FIRST（尤其薪资字段允许 NULL 时），否则不同数据库默认行为不同，可能导致排名错乱。
