pl/sql中varchar2(32767)在sql层报ora-01489，因sql引擎限制：12c前上限4000字节，12c+需max_string_size=extended才支持32767；否则必须截断、改clob或用lob函数处理。
PL/SQL里声明VARCHAR2(32767)却在SQL中报ORA-01489
不是变量声明错了，是SQL引擎根本不认这个长度。PL/SQL允许VARCHAR2(32767)，但SQL层（INSERT、SELECT、EXECUTE IMMEDIATE）在12c之前硬卡在4000字节；12c+也得MAX_STRING_SIZE=EXTENDED才可能支持32767——而且仅限新创建的对象。
检查是否生效：SELECT value FROM v$parameter WHERE name = 'max_string_size'，返回EXTENDED才算真正启用。
常见翻车点：
- 哪怕PL/SQL里拼出3万字的
long_str，一塞进INSERT INTO t(vcol) VALUES (long_str)就崩 -
EXECUTE IMMEDIATE执行动态SQL时，语句本身超32767字节也会触发ORA-06502 - 用
||反复拼接大字符串，每次操作都复制副本，内存和性能双崩
LISTAGG拼接超长直接报ORA-01489怎么办
LISTAGG返回类型固定是VARCHAR2，SQL层限制死在4000字节，跟PL/SQL变量长度无关。哪怕你开了EXTENDED，函数本身不升级类型。
替代方案只有两个靠谱路径：
- 改用
XMLAGG：返回CLOB，天然绕过限制，SELECT RTRIM(XMLAGG(XMLELEMENT(E, col || ',')).EXTRACT('//text()'), ',') FROM t - 加
TO_CLOB()强制转类型：但仅适用于结果已存在且能先取到CLOB列的场景，不能解决LISTAGG自身溢出
别指望ON OVERFLOW TRUNCATE——那是Oracle 12.2+的语法，只截断不报错，但业务逻辑可能已损坏。
想存超长文本，字段该不该改CLOB
该，而且要一步到位。把VARCHAR2(4000)改成CLOB是最干净的解法，但注意三处关键细节：
- 建表或修改字段时用
ALTER TABLE t MODIFY (clob_col CLOB)，别写VARCHAR2(32767)——那只是假希望 - 插入时如果用绑定变量（如JDBC），必须显式声明为
CLOB类型，否则驱动默认当VARCHAR2处理，无声截断 - PL/SQL里操作中间变量也得声明为
CLOB，比如my_clob CLOB，别用%TYPE引用旧字段，容易继承VARCHAR2定义
赋值别用:= 'a' || 'b'，改用:= TO_CLOB('a') || TO_CLOB('b')，否则右值仍是VARCHAR2路径。
JDBC读写超长VARCHAR2/NVARCHAR2必须配哪几个参数
即使数据库开了MAX_STRING_SIZE=EXTENDED，JDBC驱动默认也不识别VARCHAR2(32767)，会映射成OTHER类型，getString()直接抛异常。
连接URL里这三个参数缺一不可：
-
useUnicode=true&characterEncoding=UTF-8：防中文乱码，尤其影响NVARCHAR2解码 -
SetBigStringTryClob=true：强制驱动把超长字符列当CLOB处理，getString()内部自动调getClob().toString() -
oracle.jdbc.useFetchSizeWithLongColumn=true：避免批量操作时因fetch size与长列冲突导致隐式转换失败
ojdbc7基本不支持，ojdbc8起需手动开这些开关——光升级jar包没用。
真正麻烦的从来不是“怎么写”，而是“在哪断”：PL/SQL变量能撑32767，SQL层卡4000，JDBC又卡一次，CLOB操作还要手动释放临时段。每个环节的类型边界都得亲手对齐，漏一个就静默截断或当场报错。
