Oracle 12c+ OFFSET/FETCH 分页性能差的主因是未命中索引导致全表扫描，需严格匹配ORDER BY字段顺序、升降序及WHERE条件建复合索引，并校验OFFSET值防无效扫描。
oracle 12c+ 用 offset/fetch 分页，不加索引或写错顺序，性能可能比 rownum 还差。
为什么 OFFSET/FETCH 在 Java 中跑得慢
Java 应用里调用 OFFSET/FETCH 语句时，常见慢在执行计划没走索引扫描，而是全表扫描或索引全扫（INDEX FULL SCAN）。根本原因不是语法本身，而是 Oracle 优化器没拿到足够信息来裁剪——它必须先排序全部匹配行，再跳过 OFFSET 行，最后取 FETCH 行。如果 ORDER BY 字段没索引，或索引顺序/方向不匹配，就会触发这个高成本路径。
无序列表：
立即学习“Java免费学习笔记（深入）”；
-
OFFSET值越大，跳过的行越多，数据库实际扫描的物理行数就越多（不是“跳过”，是“遍历后丢弃”） - Java JDBC 驱动默认不自动绑定变量类型，
OFFSET ?和FETCH NEXT ? ROWS若传入Integer而非Long，某些驱动版本会触发隐式转换，干扰执行计划复用 - Spring Data JPA 的
Pageable默认生成OFFSET/FETCH，但若底层表没建对索引，分页第 100 页可能耗时 3 秒以上
ORDER BY 索引必须严格匹配字段顺序和方向
比如 Java 查询写的是 ORDER BY status DESC, created_time ASC，那索引必须是 CREATE INDEX idx_status_time ON your_table (status DESC, created_time ASC)。少一个 DESC，或者字段顺序颠倒，Oracle 就无法用该索引直接提供已排序结果，只能回表 + 大量排序。
无序列表：
立即学习“Java免费学习笔记（深入）”；
- 复合索引中字段顺序必须与
ORDER BY子句完全一致，不能只覆盖部分字段 - 升序/降序声明要显式写出；Oracle 对
ASC默认支持，但DESC必须明确定义，否则索引不可用于降序扫描 - 如果查询带
WHERE条件（如status = 'ACTIVE'），把该字段放在复合索引最左，能同时支持过滤 + 排序，避免回表
Java 代码里别让 OFFSET 变成负数或超大值
用户手动输入页码、前端传错参数、或分页控件未校验，都可能导致 OFFSET 是负数或几百万。Oracle 不会报错，但会强制扫描前几百万行再丢弃——这等于做了一次无效全表扫描。
无序列表：
立即学习“Java免费学习笔记（深入）”；
- 在 Service 层校验
page和size：例如if (page 500) throw new IllegalArgumentException(); - 对超大
OFFSET（如 > 100000），改用游标分页（WHERE created_time ），避免深度分页 - JDBC PreparedStatement 绑定时，用
setLong()而非setInt()设置OFFSET参数，防止溢出或隐式转换
什么时候该放弃 OFFSET/FETCH 改用 ROWNUM 嵌套
当你的 Oracle 版本是 12c+，但业务场景满足以下任一条件时，手写三层 ROWNUM 嵌套反而更快：数据有强时间局部性（如查最近 7 天订单）、WHERE 条件能高效过滤、且排序字段有高选择性索引。因为 ROWNUM 写法更容易触发 COUNT STOPKEY 优化——查够指定行数就停，不扫全集。
示例对比：
SELECT * FROM (
SELECT a.*, ROWNUM rn FROM (
SELECT * FROM orders
WHERE order_date >= TRUNC(SYSDATE) - 7
ORDER BY order_id DESC
) a WHERE ROWNUM <= 20
) WHERE rn > 0;这段比 OFFSET 0 ROWS FETCH NEXT 20 ROWS ONLY 更容易命中 COUNT STOPKEY，前提是 order_id 有索引且 order_date 过滤后结果集小。
真正难处理的不是语法切换，而是同一张表上不同分页场景混用：有的按时间查最新，有的按状态查全部。这时候索引设计必须权衡，而最容易被忽略的，是分区键和排序字段的耦合——比如按天分区的表，ORDER BY event_time DESC 却没在每个分区里建局部索引，OFFSET 一上来就跨所有分区扫描。
