本质区别在于存储方式与访问约束：Nested Table 存为独立堆表（含NESTED_TABLE_ID），支持动态增删、无长度上限；VARRAY 是连续存储的定长结构，定义时须指定最大容量，超限报ORA-22165。
Oracle 中 Nested Table 和 VARRAY 的本质区别在哪
不是“嵌套表更灵活，数组更紧凑”这种模糊说法——关键在存储方式和访问约束。nested table 实际存成独立的堆表（带系统生成的 nested_table_id），支持动态增删、无长度上限；varray 是连续存储的定长结构，定义时必须指定最大容量，插入超限时直接报 ora-22165。
常见错误现象：INSERT INTO parent_table VALUES (1, my_nested_table_type()) 报 ORA-00902: invalid datatype——因为没先初始化集合，或类型未在 SQL 层可见（只在 PL/SQL 块里声明不行）。
-
Nested Table必须用CREATE TYPE在 schema 级创建，不能只在 PL/SQL 块中TYPE t IS TABLE OF ... -
VARRAY可以在 PL/SQL 块内声明，但若想在 SQL 语句中用（如SELECT查询字段），同样要CREATE TYPE - 查询
Nested Table字段需用TABLE()函数展开，例如SELECT t.col FROM parent p, TABLE(p.nested_col) t
PL/SQL 里怎么安全地操作 Nested Table 元素
直接用下标访问（如 my_nt(1)）最危险：空集合、越界、索引不连续都会抛 ORA-06533 或 ORA-06532。别依赖“我知道它有 5 个元素”。
使用场景：循环处理日志条目、批量校验参数列表、构建动态 WHERE 条件。
- 永远先检查
COUNT，而不是硬写FOR i IN 1..my_nt.COUNT LOOP——Nested Table索引可能不连续（删过中间元素后） - 用
my_nt.FIRST和my_nt.NEXT(i)遍历才可靠，例如：DECLARE<br> i PLS_INTEGER;<br>BEGIN<br> i := my_nt.FIRST;<br> WHILE i IS NOT NULL LOOP<br> -- 处理 my_nt(i)<br> i := my_nt.NEXT(i);<br> END LOOP;<br>END;
- 清空用
my_nt.DELETE，不是my_nt := my_nt_type()—— 后者只重置为 NULL，不释放内存，且再次赋值前调用COUNT会报错
多维“数组”在 Oracle 里到底该怎么模拟
Oracle 没原生二维数组，VARRAY 和 Nested Table 都只能是一维的。所谓“二维”，是靠嵌套类型实现：比如 TYPE t_row IS TABLE OF NUMBER;，再 TYPE t_matrix IS TABLE OF t_row;。
性能影响明显：两层 Nested Table 展开查数据，TABLE(TABLE(...)) 嵌套写法会让执行计划变复杂，尤其配合 JOIN 时容易走笛卡尔积。
- 如果只是 PL/SQL 内部计算，优先用
VARRAY嵌套（内存连续，访问快），例如：TYPE t_2d IS VARRAY(100) OF VARRAY(100) OF NUMBER; - 如果需要 SQL 层过滤某行某列，用
Nested Table嵌套 + 显式ROWNUM标记位置，否则无法定位“第 3 行第 2 列” - 避免三层及以上嵌套——解析慢、调试难、
COLLECT聚合时容易出ORA-22814（属性超出范围）
从 Java 或 Python 传多维数据进 Nested Table 参数时踩什么坑
JDBC/ODBC 驱动对嵌套类型支持极弱。多数情况下，PreparedStatement.setObject(idx, list, Types.OTHER) 会失败，报 ORA-00302 或静默截断。
真实使用场景：微服务后端调 Oracle 存储过程批量导入配置矩阵。
- 别指望驱动自动映射 List
- > →
Nested Table—— 必须手动转成 Oracle 自定义对象数组（ARRAY类型），且该ARRAY对应的STRUCT必须提前注册 - Python cx_Oracle 要用
connection.gettype("MY_NESTED_TYPE")获取类型，再用nt_obj = nt_type.newobject()构造，不能直接塞 Python list - 最省事的妥协方案：把多维数据 JSON 化，存在
CLOB字段里，过程内部用JSON_TABLE解析 —— 绕开类型映射，但失去强类型校验
嵌套类型的麻烦不在定义，在跨语言边界时那层薄薄的驱动适配——它既不透明，也不容错。实际项目里，宁可多建一张关联表，也别强求 JDBC 直传三层 Nested Table。
