排序慢主因是索引不匹配、内存不足致磁盘排序或未走索引；需按ORDER BY字段严格顺序建复合索引，调优PGA内存，并通过执行计划确认是否出现SORT ORDER BY。
排序慢，八成不是sql写得差，而是索引没对上、内存没调好、或者根本没走索引。
ORDER BY字段没索引，Oracle只能硬排序
Oracle执行ORDER BY时，如果排序字段没有合适索引，就会触发磁盘排序（TEMP表空间写入），I/O飙升，响应变卡。尤其当结果集超过几万行，性能断崖式下跌。
- 单字段排序：直接建B-tree索引，比如
CREATE INDEX idx_sales_amt ON sales_team(sales_amount) - 多字段排序：必须按
ORDER BY的**严格顺序**建复合索引，例如ORDER BY deptno, hiredate DESC→ 索引要写成(deptno, hiredate DESC)，不能反过来 - 降序排序：Oracle 12c+才真正支持
DESC索引；11g及更早版本即使写了DESC，索引也只按升序物理存储，无法加速ORDER BY ... DESC - 注意隐式转换：如果
ORDER BY TO_CHAR(date_col)，索引失效——改用函数索引或提前格式化字段
索引存在但没被用上，查执行计划最准
建了索引≠Oracle就用。常见原因包括统计信息过期、绑定变量窥探失效、WHERE条件用了函数导致索引列无法匹配。
- 用
EXPLAIN PLAN FOR SELECT ... ORDER BY ...后查DBMS_XPLAN.display，重点看OPERATION列是否出现INDEX RANGE SCAN或INDEX FULL SCAN；若看到SORT ORDER BY或SORT AGGREGATE，说明排序没走索引 - WHERE和ORDER BY混用时，优先保证WHERE条件能走索引；否则Oracle可能放弃索引，全表扫描后再排序
- 复合索引中，只有前导列（最左列）出现在WHERE中，后续列才可能用于排序；比如索引
(status, created_date)，WHERE status = 'A' ORDER BY created_date可走索引；但WHERE created_date > SYSDATE-7就完全无效
PGA内存太小，排序被迫落盘
即使有索引，如果数据量大、并发高，Oracle仍可能因内存不足把排序写到临时表空间，速度骤降。
- 检查当前策略：
SHOW PARAMETER workarea_size_policy—— 若是AUTO，则由pga_aggregate_target统一管理；若是MANUAL，需手动设sort_area_size - 不建议全局调大
sort_area_size（已废弃于10g+），应优先确保pga_aggregate_target合理（通常设为SGA的20%~25%） - 对单个大排序语句，可用
/*+ USE_NL(t) */等hint引导执行计划，或拆成带ROWNUM的分页查询，避免一次全排 - Top-N查询（如
FETCH FIRST 10 ROWS ONLY）自动启用优化算法，比ORDER BY ... ROWNUM 更可靠
PL/SQL里排序别在循环里做
在FOR rec IN (SELECT ...) LOOP里对每条记录再SELECT ... ORDER BY，等于把排序逻辑从“一次集中处理”退化成“N次独立排序”，I/O和CPU双爆炸。
- 把排序逻辑前置：把需要排序的数据一次性查出、存入集合（如
TYPE t_tab IS TABLE OF sales_team%ROWTYPE），再用ORDER BY或客户端逻辑排 - 避免游标嵌套查询：游标定义本身应包含完整
ORDER BY，而不是靠循环内动态拼SQL - 批量操作优先：用
BULK COLLECT INTO+FORALL替代逐行处理，减少上下文切换开销
索引不是越多越好，排序优化也不是堆参数就能解决。真正卡点往往藏在执行计划里那行SORT ORDER BY STOPKEY是否出现、ROWS预估是否准确、以及TEMP段有没有被反复擦写——这些细节比语法本身更决定成败。
