FETCH FIRST 不支持游标变量直接绑定，必须用 ROW_NUMBER() 封装分页逻辑或动态拼接 SQL；Oracle 明确禁止在 OFFSET/FETCH 中使用运行时变量，推荐子查询 + ROW_NUMBER() 的静态方案。
FETCH FIRST 本身不支持游标变量直接绑定，所谓“FETCH FIRST 配合游标”本质上是混淆了两个不同层级的机制：SQL 行限制子句（FETCH/OFFSET）作用于 SELECT 语句执行结果集，而游标（REF CURSOR）是 PL/SQL 中用于传递结果集的句柄——它不能在声明时就嵌入 FETCH NEXT，必须在 OPEN 时把完整 SQL 作为字符串或静态语句传入。
FETCH FIRST 无法在游标声明里直接写
你不能这样写：OPEN p_cursor FOR SELECT * FROM emp ORDER BY emp_id OFFSET :offset ROWS FETCH NEXT :limit ROWS ONLY; —— 这在 PL/SQL 中语法错误。Oracle 不允许在动态游标 OPEN 语句中把绑定变量用于 OFFSET 和 FETCH 的数值位置（即不支持 :offset 替换行数）。即使使用静态 SQL，OFFSET 和 FETCH 后的数值也必须是字面量或编译期可确定的表达式（如 20、10 * 2），不能是运行时变量。
- 错误示例：
OFFSET v_offset ROWS→ 报错PLS-00103: Encountered the symbol "V_OFFSET" - 可行替代：拼接字符串 +
EXECUTE IMMEDIATE，但需严格校验参数防注入 - 更安全做法：用
ROW_NUMBER()+ 子查询封装分页逻辑，再 OPEN 游标
用 ROW_NUMBER() 封装后 OPEN 游标才是稳定方案
真正能和 REF CURSOR 优雅协作的，是把分页逻辑下沉到子查询里，用 ROW_NUMBER() 标记序号，再在外层过滤。这样整个语句是静态 SQL，可直接绑定变量，且 Oracle 优化器对 ROW_NUMBER() + 索引的识别足够成熟。
- 典型结构：
OPEN p_cursor FOR SELECT empno, ename, salary FROM ( SELECT empno, ename, salary, ROW_NUMBER() OVER (ORDER BY emp_id) rn FROM employees WHERE dept_id = :dept_id ) WHERE rn BETWEEN :start_row AND :end_row; -
:start_row=(page_no - 1) * page_size + 1，:end_row=page_no * page_size - 必须确保
ORDER BY列有索引，否则ROW_NUMBER()会触发全表扫描+排序 - 相比
OFFSET，该写法在深分页（如第 1000 页）下执行计划更可控，避免优化器误判
真要用 FETCH FIRST + 游标？只能走动态 SQL
如果坚持用 FETCH FIRST 语法，唯一办法是拼接字符串并用 EXECUTE IMMEDIATE 构造完整语句，再赋值给游标。但这要求你手动处理引号、类型转换和 SQL 注入风险。
- 示例片段：
v_sql := 'SELECT empno, ename FROM employees ORDER BY emp_id ' || 'OFFSET ' || TO_CHAR((p_page - 1) * p_size) || ' ROWS ' || 'FETCH NEXT ' || TO_CHAR(p_size) || ' ROWS ONLY'; OPEN p_cursor FOR v_sql; - 隐患：若
p_page或p_size来自用户输入且未校验，可能引发 SQL 注入或数字溢出 - 性能上无优势：底层仍需跳过前 N 行，和
ROW_NUMBER()方案一样要扫描 - Oracle 官方文档明确指出：带绑定变量的
OFFSET/FETCH数值不被支持
真正需要关注的不是“怎么把 FETCH FIRST 塞进游标”，而是分页场景下数据访问模式是否合理——比如第 500 页之后还让用户翻页，不如加条件过滤或改用游标分批拉取（FETCH ... BULK COLLECT INTO）。游标本身不是为“跳过大量行”设计的，它的价值在于流式消费，而不是随机跳转。
