Oracle PL/SQL本身不执行排序，真正排序由SQL引擎完成；优化关键是避免PL/SQL层触发低效排序，通过匹配索引、调优PGA、验证执行计划等手段使ORDER BY走索引扫描而非磁盘排序。
Oracle PL/SQL 本身不直接执行排序，真正做排序的是 SQL 引擎；所谓“PL/SQL 优化大数据量排序”，本质是避免在 PL/SQL 层触发低效的排序行为，把排序压力交给数据库优化器，并通过索引、执行计划、内存配置等手段让 ORDER BY 尽可能走索引扫描而非磁盘排序。
为什么 PL/SQL 里写 ORDER BY 容易出性能问题
PL/SQL 中调用含 ORDER BY 的查询（比如游标或隐式结果集），若没对应索引，Oracle 会在 PGA 中做 SORT ORDER BY 操作。当数据量大、sort_area_size 不足时，就会 spill 到临时表空间，产生大量物理 I/O 和 TEMP 段争用。
- 常见错误现象：
SELECT * FROM big_table ORDER BY create_time DESC执行慢，V$SQL_PLAN显示SORT ORDER BY或SORT ORDER BY STOPKEY节点，且IO_COST高 - 根本原因：缺少匹配的索引，或索引列顺序/方向与
ORDER BY不一致 - 注意：PL/SQL 块内用
BULK COLLECT INTO拿结果再自己排序（如用嵌套表 +ORDER BY）是灾难性做法——等于把排序从 C 语言引擎搬到 PL/SQL 解释器，完全失去优化器能力
用复合索引消除 ORDER BY 排序操作
核心目标是让执行计划中不出现 SORT ORDER BY，而是走 INDEX RANGE SCAN 或 INDEX FULL SCAN 后直接按物理顺序返回。
- 索引列顺序必须严格匹配
ORDER BY子句顺序，例如ORDER BY status, last_update DESC→ 索引需建为(status, last_update DESC) - 升序/降序需显式声明：Oracle 11g+ 支持
DESC索引；旧版本可用INDEX_DESC提示，但不如原生降序索引稳定 - 如果
WHERE条件也存在，优先保证过滤列在前、排序列在后，例如WHERE dept_id = 10 ORDER BY hire_date DESC→ 索引(dept_id, hire_date DESC) - 避免在索引列上用函数或表达式：
ORDER BY UPPER(name)无法利用name上的普通索引
ROWNUM 分页 + 排序必须配对索引
典型分页写法 SELECT * FROM (SELECT a.*, ROWNUM rn FROM (SELECT * FROM t ORDER BY x) a WHERE ROWNUM 10，若无合适索引，内层 ORDER BY 会先全表排序再取前 20 行，代价极高。
- 必须为
ORDER BY列建索引，且该索引能覆盖整个排序范围（即不需要回表取其他字段）——否则即使消除了排序，仍要大量随机 I/O 回表 - 更优写法是用
OFFSET ... FETCH NEXT（Oracle 12c+），配合索引后执行计划会出现COUNT STOPKEY，表示扫到第 N 行就停，不继续遍历 - 如果业务允许，用
WHERE last_update > :last_seen替代ROWNUM分页，彻底避开排序压力
PGA 和临时表空间不是万能解药
调大 sort_area_size（或 pga_aggregate_target）只能缓解小规模排序溢出，对千万级排序无效，还可能挤占其他会话内存。
- 临时表空间写满会导致
ORA-01652: unable to extend temp segment，这不是索引问题，是架构信号 -
ALTER SESSION ENABLE PARALLEL DML对ORDER BY无直接帮助；并行排序（PX SEND QC+PX RECEIVE）只在特定并行查询场景下生效，且需额外许可 - 真正有效的“绕过”方式：用物化视图预排序、用分区表按时间范围裁剪、或把排序逻辑前置到应用层（仅适用于结果集不大且网络带宽充足）
最常被忽略的一点：开发人员常以为“加了索引就万事大吉”，但没验证执行计划是否真用了索引扫描而非索引快速全扫（INDEX FAST FULL SCAN）——后者仍需排序。务必用 EXPLAIN PLAN FOR + DBMS_XPLAN.DISPLAY 看实际访问路径和是否含 SORT 节点。
