Oracle 12c+中OFFSET FETCH不能直接拼接PL/SQL变量，否则触发硬解析、索引失效；必须用绑定变量（如USING）复用执行计划，并确保ORDER BY字段有索引。
oracle 12c+ 分页必须用 offset fetch，但直接拼接变量会触发硬解析、丢失索引优势——关键在绑定变量写法和 pl/sql 变量传入方式。
为什么 OFFSET FETCH 语句里不能直接写 PL/SQL 变量
PL/SQL 块中执行动态 SQL 时，如果把 OFFSET 和 FETCH NEXT 的数值直接拼进字符串（比如 'OFFSET ' || v_offset || ' ROWS FETCH NEXT ' || v_size || ' ROWS ONLY'），Oracle 会为每个不同参数组合生成独立执行计划，导致大量硬解析、共享池争用，且无法复用索引扫描路径。
常见错误现象：ORA-00933: SQL command not properly ended（拼接语法错）、执行计划显示全表扫描（索引失效）、高 CPU 占用。
正确做法是：用绑定变量占位，让 Oracle 复用执行计划：
DECLARE
v_offset NUMBER := 20;
v_size NUMBER := 10;
CURSOR c IS
SELECT * FROM employees
ORDER BY employee_id
OFFSET :offset ROWS FETCH NEXT :size ROWS ONLY;
BEGIN
OPEN c USING v_offset, v_size;
-- ... 处理结果
END;
OFFSET FETCH 在 PL/SQL 中的三种安全传参方式
不是所有上下文都支持相同语法。以下方式按推荐顺序排列：
- 静态 SQL +
OPEN ... USING：最稳定，适用于已知结构的游标，绑定变量自动适配类型 - 动态 SQL +
EXECUTE IMMEDIATE ... USING：需显式声明INTO或BULK COLLECT INTO，且OFFSET/FETCH后必须用冒号绑定，不能写成表达式 - 存储过程参数直接作为绑定值：定义为
IN NUMBER，在 SQL 中直接写OFFSET p_offset ROWS—— 这种写法在 12.2+ 支持，但 12.1 不支持，容易误踩版本坑
注意：OFFSET 和 FETCH 后面的值不能是子查询、函数调用或算术表达式，例如 OFFSET (v_page - 1) * v_size ROWS 是非法的，必须提前算好再传入。
排序字段无索引时 OFFSET FETCH 性能崩塌的真实原因
OFFSET 10000 ROWS FETCH NEXT 20 ROWS ONLY 看似只取 20 行，但 Oracle 必须先定位到第 10001 行——它不会跳过前 10000 行，而是逐行扫描并计数，直到满足 OFFSET 条件。若 ORDER BY 字段没索引，就是全表扫描 + 全排序，I/O 和内存开销陡增。
验证方法：查 V$SQL_PLAN，看是否出现 SORT ORDER BY STOPKEY（健康）还是 SORT ORDER BY（危险）。
优化要点：
- 必须为
ORDER BY列建索引，复合条件时把过滤字段放前面，排序字段放后面，例如WHERE status = 'A' ORDER BY created_time→ 建(status, created_time)索引 - 避免在排序字段上用函数，如
ORDER BY UPPER(name)会让索引失效 - 若业务允许，改用键集分页（keyset pagination）：用上一页最后一条的
employee_id作为下一页起点，WHERE employee_id > :last_id ORDER BY employee_id FETCH NEXT 20 ROWS ONLY，性能几乎不随页码增长
PL/SQL 中分页逻辑绕不开的两个细节
一是 ROWNUM 和 OFFSET FETCH 对空结果处理不一致：OFFSET 超出总行数时返回空集，而 ROWNUM 嵌套写法若内层 WHERE ROWNUM 没匹配到行，外层 WHERE rn >= M 仍可能报错或逻辑混乱；二是 FETCH NEXT n ROWS ONLY 的 n 最大支持 1000000，超限会报 ORA-00972: identifier is too long（实际是语法解析失败，非长度问题）。
最容易被忽略的是：当分页参数来自用户输入（如 Web 请求），必须做范围校验——OFFSET 不能为负，FETCH 不能为 0 或超百万，否则直接报错中断整个 PL/SQL 块。别指望数据库帮你兜底。
