Oracle PL/SQL中高效分页的核心是避免硬解析和索引失效：必须用绑定变量（OPEN...USING或EXECUTE IMMEDIATE...USING），禁用字符串拼接；ORDER BY字段须有匹配联合索引，否则触发全排序；版本兼容需统一用USING，避免12.1/12.2参数传参陷阱。
Oracle PL/SQL 中实现高效分页，核心不是“怎么写语法”，而是“怎么避免硬解析 + 怎么不让索引失效”。直接拼接 OFFSET 和 FETCH 数值的字符串，性能会断崖式下跌——这不是写法问题，是执行计划被破坏的问题。
PL/SQL 里用 OFFSET FETCH 必须走绑定变量
在 PL/SQL 块中写 OFFSET v_offset ROWS FETCH NEXT v_size ROWS ONLY 是非法的，Oracle 会报 ORA-00933 或静默退化为全表扫描。真正能复用执行计划的方式只有一种：把数值当绑定参数传入。
- 静态游标必须用
OPEN ... USING，不能在 SQL 字符串里拼变量 - 动态 SQL 必须用
EXECUTE IMMEDIATE ... USING，且OFFSET和FETCH后只能跟冒号绑定名（如:offset），不能是表达式或函数调用 -
OFFSET (v_page - 1) * v_size ROWS这类写法直接报错，必须提前算好再传
ORDER BY 字段没索引时，OFFSET FETCH 就是性能黑洞
哪怕只取 20 行，OFFSET 10000 ROWS 也会强制 Oracle 扫描并计数前 10001 行。如果 ORDER BY 字段没索引，执行计划里会出现 SORT ORDER BY（全排序），而不是健康的 SORT ORDER BY STOPKEY。
- 验证方法：查
V$SQL_PLAN，看OPERATION列是否含STOPKEY - 复合排序字段（如
ORDER BY status, created_time）必须建对应顺序的联合索引 - NULL 值多的字段慎作排序依据，容易让索引选择率变差
12.1 和 12.2+ 对存储过程参数传参支持不一致
有人写 OFFSET p_offset ROWS 在存储过程中能跑通，换台库就报错——这是版本陷阱。Oracle 12.1 不支持在 SQL 文本中直接引用存储过程的 IN 参数名作 OFFSET 值，12.2+ 才放开限制。
- 安全写法：统一用
USING绑定，兼容所有 12c+ 版本 - 别依赖“看起来能运行”，要查
V$VERSION确认具体小版本 - 若需向下兼容 11g，只能退回
ROWNUM嵌套写法，但必须严格按两层结构：内层ORDER BY + ROWNUM ，外层过滤rn > start_num
最易被忽略的一点：分页不是孤立 SQL 的事，它和前端跳页逻辑强耦合。用户猛点“第100页”，OFFSET 9990 会立刻暴露索引和执行计划的真实质量——这时候再调优就晚了，得从第一次写 PL/SQL 游标时就卡死绑定方式和索引定义。
