Oracle触发器中不能用:OLD.clob_col = :NEW.clob_col判断LOB变更，因二者仅为locator指针，比较无意义且易报ORA-22275；应改用UPDATING('COLUMN_NAME')元数据判断，安全可靠。
直接在触发器里对 CLOB 或 BLOB 字段做 :OLD.col / :NEW.col 比较会失败——Oracle 触发器不支持 LOB 字段的直接值比较，:OLD.clob_col 和 :NEW.clob_col 返回的是 locator（指针），不是内容，拿它们直接拼 SQL 或判等效，结果不可靠、常报 ORA-22275。
为什么不能用 :OLD.clob_col = :NEW.clob_col 判断变更？
LOB 字段在行级触发器中暴露的是 locator，两个 locator 即使指向相同内容，内存地址也不同；若内容为空或为 NULL，locator 可能根本无效。直接比较返回 FALSE 或抛异常，无法反映真实内容是否变化。
-
:OLD.clob_col IS NULL和:NEW.clob_col IS NULL只能判断 locator 是否为空，不能说明内容空或未变 -
DBMS_LOB.COMPARE(:OLD.clob_col, :NEW.clob_col)理论上可行，但触发器内调用有严重风险：大 LOB 比较会阻塞、超时、拖慢 DML，且在 BEFORE 触发器中:OLDlocator 可能尚未就绪 - 更隐蔽的问题：如果触发器里执行
SELECT ... INTO再读 LOB 内容，会破坏事务一致性，还可能因未加FOR UPDATE报 ORA-22275
安全可行的变更追踪方案：只记录变更事件，不比内容
真正稳定的做法是放弃“精确比对内容”，转为“标记字段被修改”——只要 DML 语句显式更新了该 LOB 列，就认为它变了。这依赖 Oracle 的 UPDATING('COLUMN_NAME') 函数，它不访问 LOB 数据，纯元数据判断，零开销、100% 可靠。
- 在
BEFORE UPDATE触发器中，用IF UPDATING('CONTENT_CLOB') THEN ...判断该列是否出现在 SET 子句里 - 配合
INSERTING/DELETING，可覆盖 INSERT/UPDATE/DELETE 三类操作，无需读取 LOB 值 - 日志表字段设计建议：存
table_name、row_id、operation（'I'/'U'/'D'）、lob_column、update_time，不存旧值/新值 - 若业务强要求记录变更前后摘要（如长度、MD5），应在应用层或异步作业中处理，而非触发器内调用
DBMS_LOB.GETLENGTH或STANDARD_HASH
想存 LOB 内容快照？必须绕过触发器走存储过程
真要落库保存变更前后的 CLOB 片段（比如前 200 字符），触发器不是合适载体。应把 LOB 提取逻辑封装进独立存储过程，由应用在 COMMIT 后显式调用，或通过 DBMS_SCHEDULER 异步执行。
- 触发器内调用
DBMS_LOB.SUBSTR(:OLD.clob_col, 200, 1)极易失败：ORA-22275（locator 无效）或 ORA-06502（字符集转换错误） - 正确路径：触发器只写
audit_log表，含rowid和operation；另建过程proc_capture_lob_snapshot(p_rowid ROWID)，用SELECT clob_col INTO l_clob FROM t WHERE ROWID = p_rowid FOR UPDATE安全获取 locator，再分段读 - 注意：哪怕只取前 200 字符，也要防
DBMS_LOB.SUBSTR在空 LOB 上返回 NULL 而非空字符串，需先IF DBMS_LOB.GETLENGTH(:OLD.clob_col) > 0 THEN ...
LOB 字段的变更追踪本质是权衡：要实时性就舍精度，要内容快照就得离开触发器上下文。硬在触发器里啃 LOB 值，99% 的坑都来自 locator 生命周期和事务隔离的错配。
