pl/sql关联数组必须用index by声明（如index by pls_integer）才支持exists和count；嵌套表或varray不支持，键不可为date或对象；exists仅判断是否显式赋值，count返回已赋值键数，delete可清空或按键删除。
pl/sql 关联数组怎么声明才支持 exists 和 count
必须用 index by 声明为索引表（即关联数组），且类型要基于 pls_integer 或 varchar2 等允许作为键的类型。用 index by binary_integer 也能用，但 pls_integer 更安全、性能略好。
常见错误是误写成嵌套表或可变数组（TABLE OF ... 不带 INDEX BY），它们不支持 EXISTS，调用会报 PLS-00306: wrong number or types of arguments。
-
TYPE t_map IS TABLE OF VARCHAR2(100) INDEX BY PLS_INTEGER;✅ 可用EXISTS/COUNT -
TYPE t_nested IS TABLE OF VARCHAR2(100);❌ 没有INDEX BY，不是关联数组，不支持EXISTS - 键类型不能是
DATE或自定义对象——编译直接报错PLS-00357: use of 'DATE' is invalid in this context
EXISTS 判断时为什么总是返回 FALSE
因为关联数组的键是稀疏的，未赋值的下标不存在，哪怕你用 my_arr(5) := NULL 赋了空值，my_arr.EXISTS(5) 仍为 TRUE；但若跳过 5 直接赋 my_arr(6)，那 my_arr.EXISTS(5) 就是 FALSE——这和数组“初始化”无关，只看是否显式赋过值。
- 不要用循环从 1 到
my_arr.COUNT然后无脑查EXISTS(i)，中间可能大片缺失 - 正确遍历方式是用
FIRST/NEXT：先l_idx := my_arr.FIRST;，再WHILE l_idx IS NOT NULL LOOP ... l_idx := my_arr.NEXT(l_idx); END LOOP; -
EXISTS不触发隐式初始化，但my_arr(999)单独引用未赋值键，会自动创建该键（值为NULL），之后EXISTS(999)就变成TRUE
COUNT 返回值为什么比你以为的“元素个数”还小
COUNT 返回的是当前已赋值的键的数量，不是最大下标，也不是内存占用长度。比如你只设了 arr(-100) 和 arr(1000)，arr.COUNT 就是 2，不是 1101。
- 它和
EXISTS逻辑一致：只统计显式赋过值（含NULL）的键 - 对
VARCHAR2键的关联数组，COUNT同样有效，比如map('user_123')和map('role_admin')→COUNT = 2 - 别拿
COUNT当数组长度用，也别和LAST - FIRST + 1混淆——后者在稀疏时完全不可靠
用 DELETE 清空后 COUNT 是 0，但 EXISTS 还能用吗
可以，而且行为很干净：DELETE 后整个集合变为空，COUNT = 0，所有 EXISTS(n) 都返回 FALSE，FIRST/NEXT 返回 NULL。但注意两种删法的区别：
-
my_arr.DELETE;—— 彻底清空，推荐用于重置 -
my_arr.DELETE(5);—— 只删键为 5 的条目（无论键是数字还是字符串） -
my_arr.DELETE(2, 8);—— 仅对PLS_INTEGER键有效，删闭区间内存在的键；若 3、7 存在而 4、5 不存在，只删 3 和 7
关联数组没有「容量」概念，也没有「收缩内存」操作，DELETE 是唯一可控的清理手段。反复增删不会泄漏，但也不自动压缩——这是设计使然，不是 bug。
键的类型选择和 DELETE 的粒度控制，是实际写业务逻辑时最容易被忽略的两个点。
