DBMS_LOB.COMPARE 返回 NULL 当 AMOUNT
DBMS_LOB.COMPARE 参数必须显式校验边界值
直接传入超大 amount 或负数 offset 会导致返回 NULL，而不是报错——这意味着你可能误判“相等”。Oracle 实际只在参数 amount 、offset_1 或 offset_2 时返回 NULL，其他越界（如 offset 超过 LOB 实际长度）会静默截断比较范围。
实操建议：
- 用
dbms_lob.getlength(lob)先查两个 CLOB 的真实字符长度，再设amount := least(len1, len2) - 避免硬写
4294967295——这是旧文档遗留的 magic number，新版本推荐用dbms_lob.lobmaxsize（值为 9223372036854775807），但注意它仍是BIGINT，PL/SQL 中声明为INTEGER会隐式截断 - 若只想比前 N 个字符，确保
offset_1和offset_2都 ≥ 1，且 ≤ 对应 LOB 长度，否则比较结果不可靠
比较前必须锁定行，否则 ORA-22920 会中断执行
DBMS_LOB.COMPARE 本身不改数据，但如果你在 PL/SQL 中先 SELECT ... INTO 拿到 LOB 定位器，再调用 compare，Oracle 仍要求源行被锁定——尤其当 LOB 列启用了存储内联（in-row）或缓存策略时，定位器可能指向未提交的内存副本。
常见错误现象：PL/SQL 块运行到 dbms_lob.compare(...) 突然抛 ORA-22920: row containing the LOB value is not locked，而 SELECT 语句本身没加 FOR UPDATE。
实操建议：
- 所有
SELECT ... INTO lob_var FROM table WHERE ...必须带FOR UPDATE，哪怕只是读操作 - 如果表有主键，锁定粒度可控制在行级；若无主键，考虑加
FOR UPDATE SKIP LOCKED避免阻塞 - 不要试图用
dbms_lob.substr先取小段字符串再用普通=比较——CLOB 可能含不可见控制符，且 substr 截断后丢失上下文
CLOB 比较本质是字符级，BLOB 才是字节级
同一个 DBMS_LOB.COMPARE 函数签名，对 CLOB 和 BLOB 的语义完全不同：amount 对 CLOB 是“字符数”，对 BLOB 是“字节数”。若误把 UTF-8 编码的 CLOB 当作 BLOB 传入，或反之，结果必然错乱。
典型陷阱：数据库字符集是 AL32UTF8，某 CLOB 存了中文“你好”，长度为 2 字符，但底层占 6 字节。若你设 amount = 3 并当作 BLOB 比较，实际只取前 3 字节（可能截断一个汉字），返回值就失去意义。
实操建议：
- 明确变量类型：声明时用
clob就走字符逻辑，用blob就走字节逻辑，别混用 - 跨库比对时，确认两端字符集一致；若不一致，先用
convert()统一编码再比 - 调试时可用
dump(lob_col, 10, 1, 20)查看前 20 字节原始内容，验证是否真按字符预期切分
海量 CLOB 直接全量比较性能极差，要分段+提前退出
一个 100MB 的 CLOB 全量调用 DBMS_LOB.COMPARE，即使内容在第 1 字节就不同，函数仍会尝试加载并比对完整块——这不是 bug，是 Oracle LOB 定位器机制决定的：它不支持“流式短路比较”。
性能影响明显：单次调用可能耗时数秒，且占用大量 PGA 内存；并发多路时易触发 ORA-04030（内存不足）。
实操建议：
- 分段比：用循环 +
dbms_lob.substr提取每 32767 字符一段，逐段 compare；一旦某段返回非 0，立即EXIT - 加长度预检：先比
dbms_lob.getlength(clob1)和dbms_lob.getlength(clob2)，不等直接返回 -1/1，省掉后续开销 - 生产环境慎用全量 compare；如需定期校验，优先建物化视图或用
DBMS_COMPARISON包（要求 11g+，支持增量扫描）
真正难处理的不是语法，而是 LOB 定位器背后那层“延迟加载 + 缓存一致性”机制——它让看似简单的比较，变成一次隐式的全量数据触达。别信“一次 compare 解决所有”的说法。
