嵌套表支持动态扩容、删元素、建主键和索引，可JOIN TABLE()查询内部值并支持稀疏操作；VARRAY长度固定、不支持DELETE和元素级DML，无法单独索引或分区，查询能力受限，仅支持MEMBER OF语法。
因为嵌套表支持动态扩容、可删元素、能建主键约束，而VARRAY写死长度、不支持DELETE操作、无法在WHERE里查内部值——这些不是设计偏好，是SQL引擎对持久化列的硬性要求。
嵌套表能建物理存储表，VARRAY不能
NESTED TABLE必须配合STORE AS子句声明独立的存储表，Oracle才允许它作为列类型写入数据库；VARRAY直接作为列类型虽合法，但它的数据和父记录挤在同一行里，没法单独建索引、没法分区、没法做DML级审计。一旦业务要加字段、改结构、导历史数据，VARRAY列就卡死在“整列读写”这一层，没法拆解。
-
CREATE TABLE parent (id NUMBER, nt_col my_nested_table_type) NESTED TABLE nt_col STORE AS nt_store;—— 必须带STORE AS，否则报错 -
CREATE TABLE parent (id NUMBER, var_col my_varray_type);—— 合法，但var_col只能整体UPDATE，不能UPDATE ... SET var_col[2] = 'x'
VARRAY在WHERE子句中几乎不可查内部元素
VARRAY只支持COLUMN MEMBER OF这种语法查是否包含某值，不能用=、LIKE、IN或函数索引加速查询。比如想查“所有第二项是'active'的记录”，VARRAY做不到；嵌套表却可以直接SELECT * FROM parent p, TABLE(p.nt_col) t WHERE t.column_value = 'active'，还能在t.column_value上建函数索引。
- VARRAY查元素：仅
WHERE var_col MEMBER OF some_varray_list，且some_varray_list得是变量或字面量，不能是子查询结果 - 嵌套表查元素：可
JOIN TABLE()、可EXISTS (SELECT 1 FROM TABLE(p.nt_col) t WHERE ...)、可WHERE t.column_value IS NOT NULL
嵌套表支持稀疏操作，VARRAY强制密集连续
嵌套表删掉第3个元素后，下标变成1、2、4、5，依然合法；VARRAY删掉中间元素会留空洞，但下标仍连续，EXTEND后新元素填在末尾，无法跳过已删位置插入——这导致应用层必须自己维护“逻辑顺序”和“物理下标”的映射，极易出错。持久化场景下，业务常要软删除、重排序、批量更新，嵌套表的天然稀疏性更贴合真实需求。
- 嵌套表：
v_nt.DELETE(3); v_nt(10) := 'new';合法，v_nt.COUNT返回当前非NULL元素数 - VARRAY：
v_arr.DELETE(3)报错（VARRAY不支持DELETE方法），只能v_arr(3) := NULL，但v_arr.COUNT不变，遍历时还得额外判NULL
初始化和DML写法差异暴露持久化能力边界
嵌套表在INSERT/UPDATE时必须走TABLE()函数展开，强制你面对“集合是一张表”的事实；VARRAY用字面量或变量直赋，掩盖了它无法原子化操作单个元素的问题。这个差异在开发期不明显，上线后一旦要加审计日志、做行级触发器、同步到CDC系统，VARRAY列就会变成黑盒，没法监听元素级变更。
- 嵌套表INSERT：
INSERT INTO parent VALUES (1, CAST(MULTISET(SELECT 'a','b' FROM DUAL) AS my_nested_table_type)); - VARRAY INSERT：
INSERT INTO parent VALUES (1, my_varray_type('a','b'));—— 看似简单，但后续无法对'a'或'b'单独加约束、加触发器 - ORA-22908错误几乎只出现在嵌套表DML中没写
TABLE()别名，而不是VARRAY——恰恰说明嵌套表的语义更接近标准表操作
真正容易被忽略的是：嵌套表的STORE AS表默认不带主键，如果业务需要保证每个父记录对应嵌套表里的元素唯一（比如用户权限列表不能重复授权），你得手动给nt_store表加PRIMARY KEY (nested_table_id, column_value)，否则约束只能落在应用层。这点VARRAY连想都不用想——它压根不支持这种粒度的约束。
