触发器中拼接clob必须用dbms_lob.writeappend三步法：先createtemporary，再writeappend，最后freetemporary；禁用||运算符和substr/concat，避免ora-22835、内存泄漏及静默失效。
触发器里直接拼接CLOB字段必崩
触发器中写 NEW.clob_col := :OLD.clob_col || 'suffix' 看似简洁，实际会触发 ORA-22835 或 ORA-06502。原因很直接：|| 运算符强制返回 VARCHAR2，而 VARCHAR2 在 PL/SQL 中上限是 32767 字节；哪怕两边都是 CLOB，也会隐式转换并截断或报错。
更隐蔽的问题是：如果 :OLD.clob_col 是 NULL，结果就是 NULL，不是你预期的 'suffix' —— 触发器逻辑静默失效，且不报错。
- 所有参与拼接的 CLOB 字段必须显式用
NVL(:OLD.clob_col, '')处理 - 绝不能依赖
||做 CLOB 拼接，这是类型系统硬限制，不是性能问题 - 若需追加内容，必须切换到
DBMS_LOB.WRITEAPPEND流式写入路径
在触发器中安全写入CLOB的三步法
触发器无法跳过 LOB 初始化流程。即使表字段已定义为 CLOB，:NEW.clob_col 在触发器上下文中仍是空 locator（非 NULL，但不可写）。直接调 DBMS_LOB.WRITEAPPEND 会静默失败或报 ORA-22285。
正确做法分三步，缺一不可：
- 先用
DBMS_LOB.CREATETEMPORARY(:NEW.clob_col, TRUE)创建可写临时 CLOB；TRUE表示启用缓存，避免反复 I/O - 再用
DBMS_LOB.WRITEAPPEND(:NEW.clob_col, LENGTH(v_append_str), v_append_str)追加内容（注意：LENGTH对 CLOB 返回字符数，单位匹配） - 最后必须调
DBMS_LOB.FREETEMPORARY(:NEW.clob_col)，否则每次触发都泄漏内存，几轮后可能直接 OOM
注意：DBMS_LOB.WRITEAPPEND 不支持从空值开始写，所以 CREATETEMPORARY 是前置强依赖。
触发器读取CLOB字段时的单位陷阱
如果触发器需要检查 CLOB 内容（比如做简单长度判断或关键字扫描），用 DBMS_LOB.GETLENGTH 没问题，它对 CLOB/BLOB 都返回“逻辑长度”（CLOB 是字符数，BLOB 是字节数）。但一旦用到 DBMS_LOB.READ，单位就立刻分裂：
- CLOB 场景：
offset从 1 开始计**字符位置**，amount是要读的**字符数**；数据库字符集为AL32UTF8时，“你好”占 2 字符、6 字节，amount := 2才能完整读出 - BLOB 场景：
offset和amount都按**字节**算；若误用字符长度当字节数传入，大概率截断中间字节，返回乱码或ORA-24801 - 读超长内容必须分块，单次
amount ≤ 32767（VARCHAR2上限），循环读取再拼接
常见错误是写一套通用读逻辑同时处理 CLOB/BLOB，结果在中文环境必然出错。
触发器中避免全量复制CLOB
别用 DBMS_LOB.CONCAT 或 :NEW.clob_col := DBMS_LOB.SUBSTR(...) 做内容裁剪或组合。前者每次调用都复制整个 LOB，N 次操作是 O(N²) 时间；后者 SUBSTR 返回 VARCHAR2，超长直接崩。
真正轻量的操作方式只有两种：
- 只读场景：用
DBMS_LOB.INSTR查关键字位置，返回数字，不碰内容本身 - 追加场景：坚持用
DBMS_LOB.WRITEAPPEND，它只追加、不复制已有数据 - 真要裁剪，改用
DBMS_LOB.COPY+DBMS_LOB.TRIM组合，但仅限明确知道目标长度且需保留前 N 字符的场景
最常被忽略的是：触发器执行完，临时 CLOB 必须 FREETEMPORARY。漏一次不会报错，但内存占用持续增长，直到某次触发直接失败——这个恶化过程无声无息。
