fetch first 可简化 top-n 查询，但需 oracle ≥12.1、显式 order by，且须置于 select 中而非游标声明；动态 n 用绑定变量，分页慎用 offset 避免性能衰减。
直接用 fetch first 替代 rownum 嵌套子查询，能显著降低 pl/sql 中 top-n 查询的执行计划复杂度和维护成本——但前提是 oracle 版本 ≥ 12.1 且未禁用该特性。
存储过程中写 FETCH FIRST 必须带 ORDER BY
Oracle 要求 FETCH FIRST 出现在排序后的结果集上，否则会报错 ORA-00907: missing right parenthesis（尤其在 PL/SQL 块中容易忽略）。这不是语法警告，是硬性限制。
-
FETCH FIRST 10 ROWS ONLY单独使用不报错，但语义无效：Oracle 会返回任意 10 行，不保证稳定性和可复现性 - 必须显式写
ORDER BY，哪怕只是按主键排序：ORDER BY id - 若业务逻辑本就不需要排序，但又想取前 N 行，建议加
ORDER BY rowid或ORDER BY 1（仅当确定列顺序稳定时）
BULK COLLECT INTO 配合 FETCH FIRST 的实际写法
在 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 + FETCH 的性能陷阱
在存储过程里实现分页（如第 1000 页、每页 20 条），OFFSET 19980 ROWS FETCH NEXT 20 ROWS ONLY 看似简洁，但 Oracle 仍需扫描前 19980 行 —— 这和老式 ROWNUM 嵌套一样有性能衰减。
- 真正高效分页依赖“键集分页”（Keyset Pagination）：用上一页最后一条记录的
salary和id作为条件，例如WHERE salary -
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 的语句，优化器仍可能回退到全表扫描+排序+截断的老路。
