Oracle FETCH FIRST 语法：简化存储过程 Top-N 查询的关键注意事项
先给出几个核心结论：FETCH FIRST 确实能替代 ROWNUM 嵌套子查询的传统写法，执行计划更清晰，维护成本也更低。但前提是——必须使用 Oracle 12.1 及以上版本，并且该特性未被关闭。
ORDER BY 是 FETCH FIRST 的硬性要求，不可省略
Oracle 明确规定：FETCH FIRST 必须作用于已排序的结果集，否则会直接抛出 ORA-00907 错误。该错误在 PL/SQL 块中尤为常见，因为编写时容易忽略上下文的排序要求。
- 单独使用
FETCH FIRST 10 ROWS ONLY不会报错，但语义上等同于未指定排序——Oracle 随机返回 10 行，结果既不稳定也不可复现 - 必须显式添加
ORDER BY，即使仅按主键排序：ORDER BY id - 如果业务逻辑不需要排序，但你仍想取前 N 行，可以借助
ORDER BY rowid或ORDER BY 1（前提是列顺序稳定）
BULK COLLECT INTO 的正确使用方式
在 PL/SQL 中批量获取 Top-N 记录时，存在一个常见陷阱：FETCH FIRST 不能放在游标声明中，否则会触发 PLS-00103 错误。正确做法是将其置于游标定义的 SELECT 语句内部。
- 正确写法：
DECLARE TYPE t_emp_tab IS TABLE OF employees%ROWTYPE; l_emps t_emp_tab;BEGIN SELECT * BULK COLLECT INTO l_emps FROM employees ORDER BY salary DESC FETCH FIRST 5 ROWS ONLY;END;
- 错误写法：
DECLARE CURSOR c IS SELECT * FROM employees FETCH FIRST 5 ROWS ONLY;→ 直接报错 - 如果 N 是动态值，使用绑定变量：
FETCH FIRST :n ROWS ONLY，注意:n必须是 NUMBER 类型，切勿传入字符串
分页场景下 OFFSET 的性能陷阱
在存储过程中实现分页，例如取第 1000 页、每页 20 条，使用 OFFSET 19980 ROWS FETCH NEXT 20 ROWS ONLY 虽然简洁，但不要被表象迷惑——Oracle 仍需扫描前 19980 行，与旧版 ROWNUM 嵌套写法一样，性能衰减不可避免。
- 真正高效的分页依赖“键集分页”（Keyset Pagination）：利用上一页最后一条记录的
salary和id作为过滤条件，如WHERE salary < :last_salary OR (salary = :last_salary AND id > :last_id) OFFSET适用于浅层分页，超过 100 页后建议重构逻辑，否则性能下降明显- 执行计划中若出现
COUNT STOPKEY或多次VIEW嵌套，说明优化器未选择最优路径，不要盲目信任FETCH语法本身
WITH TIES 的实用边界
当业务要求“并列第 N 名也计入结果”时，WITH TIES 确实方便。但问题在于它会导致返回行数不可控——存储过程中若使用 BULK COLLECT 接收，必须确保目标集合有足够容量，否则会引发 ORA-06502 数组越界错误。
- 例如：
FETCH FIRST 10 ROWS ONLY WITH TIES可能返回 12 行、15 行甚至更多 - 如果后续逻辑依赖固定行数（如生成固定长度的报表），则不应使用
WITH TIES - 可通过在查询后添加
COUNT(*)统计实际返回行数，再根据分支逻辑处理并列情况
归根结底，真正的难点不在于语法本身，而在于版本兼容性判断和执行计划验证。上线前务必在目标数据库上运行 EXPLAIN PLAN 对比旧写法，尤其关注 ROWS 列是否真实下降——有些看似使用了 FETCH FIRST 的语句，优化器仍可能回退到全表扫描+排序+截断的传统路径。
