关联数组必须用INDEX BY声明才能启用哈希查找机制；支持PLS_INTEGER和VARCHAR2索引，不支持DATE等类型；读取前须用EXISTS()检查，遍历用FIRST/NEXT；包级声明更实用，超10万条时应考虑SQL优化。
关联数组是 Oracle PL/SQL 中唯一能天然支持稀疏索引、无需预分配大小、且访问性能接近哈希表的内存集合类型——它就是为高频键值对检索而生的，别用嵌套表或 VARRAY 去硬凑。
为什么必须用 INDEX BY 声明索引类型
关联数组的核心标识不是“数组”，而是 INDEX BY 子句。没有它，就只是普通集合类型；有了它，Oracle 才启用内部哈希查找机制，而非顺序扫描。
-
INDEX BY PLS_INTEGER：适合整数 ID、序号类键，如emp_id、rownum -
INDEX BY VARCHAR2(n)：适合业务主键、编码、状态码等字符串键，如'ACTIVE'、'ORD-2026-001' - 不支持
DATE、BOOLEAN或自定义类型作索引；若需用日期查，转成TO_CHAR(dt, 'YYYYMMDDHH24MISS')字符串再存 - 索引值未赋值前直接读取会抛出
ORA-01403: no data found，不是 NULL —— 这是高频误判点
EXISTS() 是安全读取的必要前置动作
关联数组不会自动初始化所有索引位置，所谓“稀疏”就是指只有被显式赋值过的键才存在。跳过 EXISTS() 直接 my_tab('KEY') 取值，哪怕只查一次，也会中断执行。
- 正确模式：
IF my_tab.EXISTS('KEY') THEN v_val := my_tab('KEY'); END IF; - 批量遍历时用
FIRST/NEXT游标式遍历，而非FOR i IN 1..my_tab.COUNT（后者对稀疏数组完全失效） - 想清空全部元素？不能用
my_tab.DELETE后再my_tab := my_tab()，应直接my_tab.DELETE—— 它本身是原子操作
在包中声明比匿名块更实用的三个原因
生产代码几乎从不在匿名块里用关联数组。包级声明让类型可复用、变量可持久、逻辑可隔离。
- 类型定义写在包规范（
PACKAGE）里，多个存储过程可共用同一TYPE t_cache IS TABLE OF ... INDEX BY VARCHAR2(50) - 变量声明在包体（
PACKAGE BODY）的私有区，相当于“模块级缓存”，避免每次调用都重建 - 配合
PRAGMA SERIALLY_REUSABLE可控制内存生命周期，防止 PGA 持续膨胀（尤其在高并发短事务场景）
真正难的不是语法，而是判断什么时候该用关联数组、什么时候该退回到 SQL JOIN 或物化视图——比如键值对超过 10 万条、且需频繁范围扫描时，INDEX BY 的哈希优势就消失了，这时候内存结构反而成了瓶颈。
