MULTISET在存储过程中极少使用，因其仅支持类型完全一致的嵌套表，不兼容常用关联数组，且无法替代BULK COLLECT+FORALL提升性能，还存在隐式构造开销、错误难定位及执行计划不可靠等问题。
为什么 MULTISET 在存储过程中很少被真正用起来
multiset 操作符（如 multiset union、multiset intersect）在 oracle 中确实存在，但它的实际使用场景非常窄——它只对嵌套表（nested table 类型）有效，且要求两个集合类型**完全一致**（包括元素类型、精度、是否为 nullable）。一旦类型不匹配，就会报错 ora-00932: inconsistent datatypes，而不是隐式转换。更关键的是，它不能用于关联数组（index by table），而后者才是 pl/sql 中最常用的集合类型。
MULTISET 无法替代 BULK COLLECT + FORALL 的根本原因
很多人误以为 MULTISET 能简化批量数据合并或去重逻辑，但它本质是集合代数运算，不是性能优化工具。它不减少上下文切换，不规避 SQL 引擎与 PL/SQL 引擎之间的开销，也不支持 DML 操作。真正提升性能的仍是 BULK COLLECT 和 FORALL 的组合：
-
BULK COLLECT INTO把结果一次性载入内存，避免逐行 FETCH -
FORALL i IN 1..coll.COUNT将整个集合发给 SQL 引擎执行一次 DML，而非循环中反复调用 - 若需“合并两批数据再更新”，应先用 PL/SQL 循环合并集合变量，再
FORALL提交，而不是依赖MULTISET UNION
真要用 MULTISET？必须满足这 3 个硬条件
如果你确实在做元数据比对、权限集合运算等极少数场景，且已确认必须用 MULTISET，请严格检查：
- 两个操作对象必须是同一用户下定义的
NESTED TABLE类型，例如CREATE TYPE t_id_list AS TABLE OF NUMBER; - 声明变量时必须用该类型，不能用
TABLE OF NUMBER这类匿名嵌套表（会触发ORA-22905） - 目标表字段类型、长度、精度必须与集合元素类型完全对齐，否则
INSERT ... SELECT时直接失败
示例失败写法：SELECT CAST(MULTISET(SELECT id FROM t1) AS t_id_list) FROM dual; —— 若 t_id_list 是基于 NUMBER(10) 定义，而 t1.id 是 NUMBER(15)，就报错。
别掉进“语法可行但生产禁用”的坑
MULTISET 在小数据量下看似简洁，但实际有隐藏成本：
- 每次运算都会触发隐式构造嵌套表对象，产生额外 PGA 内存分配和 GC 压力
- 无法使用
SAVE EXCEPTIONS，出错即中断，错误定位困难 - 执行计划中显示为
COLLECTION ITERATOR PICKLER FETCH，说明它绕过了常规优化路径，统计信息不可靠 - Oracle 19c+ 对
MULTISET的并行支持极其有限，大数据量时反而比手写循环慢
真正要合并、过滤、去重集合数据，优先用 FORALL 配合临时表，或在 SQL 层用 UNION ALL/DISTINCT 处理后再 BULK COLLECT —— 这才是稳定、可观测、可压测的路径。
