order by 是 sql 层排序的唯一标准方式；pl/sql 无通用内置排序函数，仅支持在 sql 中排序或手动实现低效算法，推荐将计算逻辑下沉至 order by 并配函数索引优化。
ORDER BY 是 SQL 层排序的唯一标准方式，PL/SQL 本身不提供“对变量数组做通用排序”的内置函数。所谓“PL/SQL 自定义排序”，实际只有两类真实场景：在 SQL 查询中控制排序逻辑，或在 PL/SQL 变量（如嵌套表）中手动实现排序算法。前者高效可靠，后者低效且仅适用于极小数据量。
用 ORDER BY + 函数索引处理非标准排序需求
当你要按格式化后的时间、拼音首字母、状态优先级等“计算值”排序时，别想着在 PL/SQL 里循环比大小——直接把逻辑下沉到 SQL 层，并配函数索引避免重复计算。
- 错误做法：查出全部数据到 PL/SQL 数组，再用冒泡排序——1000 行就明显卡顿，且无法利用 Oracle 优化器
- 正确路径：把排序逻辑写进
ORDER BY子句，例如ORDER BY NLSSORT(last_name, 'NLS_SORT = SCHINESE')实现中文拼音排序 - 若该表达式高频使用，建函数索引加速：
CREATE INDEX idx_emp_pinyin ON employees (NLSSORT(last_name, 'NLS_SORT = SCHINESE')) - 注意：函数索引列必须和
ORDER BY中的表达式完全一致，包括参数顺序和字符串字面量（如'NLS_SORT = SCHINESE'不能简写为'SCHINESE'）
在 PL/SQL 嵌套表中手动排序只适用于个位数元素
如果你真要对 PLS_INTEGER 或 VARCHAR2 类型的集合变量排序（比如缓存几个配置项），可用快速排序或冒泡，但必须接受其 O(n²) 时间复杂度和不可扩展性。
- 示例中
f_bible_sort函数对字符串逐字符排序，本质是把输入当字符数组处理；它不支持多字节字符（如中文），且长度超 4000 就截断 - 快速排序需额外声明包类型（如
t_array_pkg.t_array），调用前必须初始化所有下标，否则NO_DATA_FOUND异常频发 - 任何自定义排序函数都绕不开
PLS_INTEGER溢出问题：传入n = 31做左移时，POWER(2,31)在 32 位环境下返回负数，导致结果错乱 - 别给排序函数加事务逻辑——它纯属 CPU 密集型操作，放在
FORALL或批量 DML 中反而拖慢整体性能
ROWNUM 和 ORDER BY 的执行顺序陷阱
想取排序后的前 N 行？直接写 WHERE ROWNUM 会先取 10 行再排序，结果完全随机。Oracle 的执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → ROWNUM。
- 正确写法必须用子查询包裹：
SELECT * FROM (SELECT * FROM emp ORDER BY salary DESC) WHERE ROWNUM - Oracle 12c+ 推荐用
FETCH FIRST 5 ROWS ONLY，语义清晰且优化器更友好 - 如果子查询里用了绑定变量，而外层
ROWNUM条件又依赖排序结果，可能触发硬解析——检查v$sql中PARSE_CALLS是否异常高 - 分页查第 2 页（11–20 行）时，嵌套两层
ROWNUM比用OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY多一次全排序，尤其当ORDER BY字段无索引时，I/O 直接翻倍
真正需要“自定义排序”的时候，八成是设计没对齐：要么该用 SQL 层 ORDER BY + 索引解决，要么该换用外部应用层处理。在 PL/SQL 里手写排序，就像用螺丝刀拧开芯片封装——能干，但不该干。
