深分页OFFSET越大越慢，因Oracle必须逐行扫描跳过前N行；BULK COLLECT仅加速取回阶段，无法减少跳行开销；应改用键值分页（如WHERE id > :last_id）配合BULK COLLECT批量获取。
深分页（比如 OFFSET 1000000 ROWS FETCH NEXT 100 ROWS ONLY）在 Oracle 中天然低效，BULK COLLECT 本身不能绕过 OFFSET 的跳行成本——它只是把“跳完之后的那批数据”批量拉进内存，不减少跳过的逻辑读。真要优化，得换思路：用键值分页（keyset pagination）替代偏移分页，并配合 BULK COLLECT 批量获取后续块。
为什么 OFFSET 越大越慢，BULK COLLECT 帮不上忙
OFFSET 不是游标偏移，而是让优化器强制扫描前 N 行并丢弃——哪怕只取 100 行，OFFSET 1000000 仍需定位到第 1000001 行的物理位置，执行计划里常出现大量 WINDOW SORT PUSHED RANK 或全索引扫描。此时 BULK COLLECT 只是在最后一步“把这 100 行装进集合”，对前面的扫描开销毫无缓解作用。
- 实测：对千万级表查
OFFSET 500000，逻辑读常超 200 万；换成键值分页后降到 200 左右 -
BULK COLLECT在这里唯一能省的是 PL/SQL 层的上下文切换，但占比微乎其微 - 若硬要用
OFFSET+BULK COLLECT，必须确保 SQL 已走覆盖索引，否则每次跳行都在读块
改用 WHERE + 主键/时间戳分页，再用 BULK COLLECT 批量取数
放弃 OFFSET，改用上一页最后一条记录的排序字段值作为下一页起点，例如按 id 升序分页：
SELECT * FROM orders WHERE id > :last_seen_id ORDER BY id FETCH NEXT 100 ROWS ONLY;
然后在 PL/SQL 中用 BULK COLLECT 拉这批数据：
- 声明集合类型：
TYPE t_orders IS TABLE OF orders%ROWTYPE; - 查询时绑定
:last_seen_id（注意不是表达式，如:page_size * :page_no不合法） - 用
FETCH ... BULK COLLECT INTO或静态SELECT ... BULK COLLECT INTO，都支持LIMIT防 PGA 溢出 - 取完后更新
last_seen_id := l_orders(l_orders.COUNT).id;，供下次调用
带复杂排序或复合排序时，如何安全构造 WHERE 条件
当排序依据不止一个字段（如 ORDER BY status, created_time DESC, id），WHERE 条件必须严格等价于“跳过已返回的所有行”。错误写法：WHERE status >= :last_status AND created_time —— 会漏数据或重复。
- 正确做法：把上一页最后一条的完整排序键拼成元组比较，Oracle 支持
(a,b,c) > (:a,:b,:c) - 示例：
WHERE (status, created_time, id) > (:last_status, :last_time, :last_id) - 确保这三个字段上有联合索引，且顺序与
ORDER BY完全一致 - 若字段允许 NULL，需额外处理（
IS NOT NULL或用NVL统一补值），否则元组比较行为不确定
容易被忽略的边界与陷阱
键值分页看似简单，但实际落地时几个点极易出错：
- 前端传来的
last_seen_id若被篡改或为空，会导致漏数据或全表扫——必须在 PL/SQL 入口校验非空且为有效数字 - 排序字段有重复值时（如多个订单同
created_time），仅靠该字段无法保证稳定分页，id必须作为最终决胜字段 -
BULK COLLECT后没检查collection.COUNT就直接遍历，遇到空结果会报ORA-06533: Subscript beyond count - 没加
LIMIT的FETCH ... BULK COLLECT在数据突增时可能撑爆 PGA，尤其当客户端误传极大FETCH数
真正起效的从来不是 BULK COLLECT 这一行语法，而是整个分页模型是否规避了跳行扫描——它只是让“合法的那批数据”进来得更快一点。
