Oracle存储过程拼接超32K字符串需用CLOB+DBMS_LOB.APPEND分段构建，避免PLS-00123编译错误；须先CREATETEMPORARY再APPEND，最后FREETEMPORARY释放内存。
Oracle存储过程中拼接超32K字符串会报PLS-00123错误
直接用 v_str := 'a' || 'b' || ... 拼接长文本，一旦表达式编译后长度超过约32K（确切说是PL/SQL编译器对单个语句的内部限制），就会在编译阶段报 PLS-00123: program too large。这不是运行时限制，而是编译器对“单条语句字面量长度”的硬约束——哪怕你用的是 VARCHAR2(32767) 变量也拦不住。
改用CLOB类型 + DBMS_LOB.APPEND分段构建
核心思路是绕过“单条字符串字面量”拼接，把大文本拆成小块，用 CLOB 作为载体，靠 DBMS_LOB.APPEND 增量追加：
- 声明变量必须是
CLOB，不能是VARCHAR2；DBMS_LOB.APPEND不接受VARCHAR2直接追加（会隐式转，但长度受限） - 先用
DBMS_LOB.CREATETEMPORARY初始化空临时CLOB，否则APPEND会报ORA-22275 - 每次追加内容建议控制在 32K 以内（
VARCHAR2最大长度），避免单次调用又触碰字面量上限 - 最后如果需要返回给应用，可用
DBMS_LOB.SUBSTR(clob_var, len, pos)截取，或直接绑定输出参数
示例片段：
DECLARE l_clob CLOB; l_part VARCHAR2(32767) := '...'; -- 每段≤32K BEGIN DBMS_LOB.CREATETEMPORARY(l_clob, TRUE); DBMS_LOB.APPEND(l_clob, l_part); DBMS_LOB.APPEND(l_clob, '另一段文本'); -- ... 多次追加 -- 使用 l_clob，比如写入表、返回给调用方 DBMS_LOB.FREETEMPORARY(l_clob); END;
动态SQL拼接大文本时用CLOB代替VARCHAR2参数
如果你在拼SQL再执行（比如构建大查询或DDL），别用 EXECUTE IMMEDIATE 直接传超长 VARCHAR2 字符串——11g以前 DBMS_SQL.PARSE 也只支持 VARCHAR2 输入，上限32K。正确做法：
- Oracle 11g 及以后：改用
DBMS_SQL.PARSE(c, clob_sql, ...)，第一个参数是游标，第二个可直接传CLOB - 或者统一走
EXECUTE IMMEDIATE+CLOB（12c+ 支持），但注意某些客户端工具（如旧版 PL/SQL Developer）可能不识别 CLOB 绑定 - 避免在
EXECUTE IMMEDIATE中内联超长字符串字面量，例如EXECUTE IMMEDIATE 'SELECT ... WHERE col IN (' || long_list || ')'—— 这里long_list若为拼接结果且含大量字面量，极易触发 PLS-00123
容易被忽略的边界点：临时CLOB生命周期和字符集
CLOB 不是万能胶布，两个细节常被跳过：
- 没调
DBMS_LOB.CREATETEMPORARY(..., TRUE)就直接APPEND，会报ORA-22275；没调DBMS_LOB.FREETEMPORARY，会在会话级持续占用 PGA 内存（尤其循环中反复创建） - 若源数据含中文等多字节字符，确保数据库字符集（如 AL32UTF8）与客户端一致，否则
DBMS_LOB.SUBSTR按字节截取可能切坏汉字——应优先用DBMS_LOB.GETLENGTH判断实际字符数，必要时配合CONVERT或UTL_RAW.CAST_TO_VARCHAR2处理
