multiset 不用于性能优化，仅适用于元数据比对等极窄场景；真正提速的是 bulk collect + forall；误用 multiset 会导致隐式开销、类型错误和执行计划失真。
multiset 不是用来“优化数组操作”的，它在 oracle 中几乎从不用于性能优化，反而容易引入隐式开销、类型错误和执行计划失真。
真正能提速的仍是 BULK COLLECT + FORALL，而 MULTISET 只适用于极窄的元数据比对类场景，且必须满足硬性前提。
为什么 MULTISET 不能替代 BULK COLLECT + FORALL
很多人看到 MULTISET UNION 就以为能“合并两批数据再批量更新”，但这是典型误用：
-
MULTISET运算本身不减少上下文切换，每次调用都会触发嵌套表对象的隐式构造，额外消耗 PGA 内存 - 它无法绑定到 DML（如
INSERT或UPDATE）的 VALUES 子句中，也不能直接参与FORALL - 若想“先合并再写库”，你仍得用 PL/SQL 循环把两个集合变量手动拼成一个，再
FORALL提交——MULTISET在这里纯属多一层无谓转换 - 执行计划里显示为
COLLECTION ITERATOR PICKLER FETCH，优化器无法准确估算代价，统计信息不可靠
MULTISET EXCEPT 判断集合相等的陷阱
不能写 IF coll1 = coll2 THEN —— Oracle 不支持集合类型直接比较。
- 正确做法是双向
MULTISET EXCEPT：(coll1 MULTISET EXCEPT coll2).COUNT = 0 AND (coll2 MULTISET EXCEPT coll1).COUNT = 0 - 但前提是
coll1和coll2必须声明为同一具名嵌套表类型（如t_id_list），不能是匿名类型TABLE OF NUMBER，否则报ORA-22905 - 未初始化的嵌套表变量参与运算会直接抛
ORA-06530，必须显式赋初值：coll1 := t_id_list(); -
CARDINALITY()对空集合返回NULL，所以COUNT更安全；用NVL(CARDINALITY(...), 0)也行，但多一次函数调用
MULTISET INTERSECT 的重复计数逻辑常被误解
它不是数学交集，而是多重集（multiset）交集：每个元素保留其在两边出现次数的较小值。
- 例如：
t1 := t_id_list(1,1,2); t2 := t_id_list(1,2,2,2);t1 MULTISET INTERSECT t2结果是t_id_list(1,2)（不是(1)，也不是去重后的(1,2)） - 如果你要的是“是否存在共同元素”，用
CARDINALITY(t1 MULTISET INTERSECT t2) > 0即可，但注意 NULL 处理 - 如果目标是“取唯一交集”，别用
MULTISET，改用SELECT DISTINCT ... FROM TABLE(t1) INTERSECT SELECT DISTINCT ... FROM TABLE(t2) - 在 WHERE 子句中用
MULTISET表达式会导致全表扫描，索引失效；高频查询务必提前物化或改用 JOIN
真要用 MULTISET？先过这三关
跳过任意一条，生产环境就该禁用。
- 两个操作对象必须是同一用户下定义的具名嵌套表类型，例如
CREATE TYPE t_str_list AS TABLE OF VARCHAR2(100); - 变量声明必须用该类型，不能用
DECLARE v1 t_str_list;以外的写法；尤其不能用TABLE OF VARCHAR2(100)这种匿名类型 - 涉及 INSERT 或 UPDATE 时，目标字段类型、精度、是否 nullable 必须与嵌套表元素类型完全一致，差一位数字精度（比如
NUMBER(10)vsNUMBER(11)）就会报ORA-00932
最常被忽略的是类型一致性检查——它发生在编译期，不是运行期，错误信息又极其笼统，排查成本远高于手写循环。
