Oracle SQL：处于事务中时，修改BLOB为何仍需锁定对应行？

首先要明确：普通列更新和BLOB定位器操作的锁定对象完全不同。

普通列执行UPDATE时，Oracle会直接锁定基表的目标行——因为修改的是行数据块本身，锁的作用是阻止其他事务对该行的DML操作。但BLOB默认存储在行外的LOB段中，你通过定位器读写BLOB时，操作的是LOB段而非基表行，所以首次写入BLOB启动事务，但不会自动锁定基表的对应行，这就是官方文档要求手动锁行的核心原因。

不手动锁行直接用定位器读写BLOB的风险 #

• 基表行被并发修改/删除，导致数据关联失效
  比如你通过SELECT拿到BLOB定位器后，未锁行：

  -- 事务1：获取定位器，未锁行
  SELECT blob_col INTO l_blob FROM t WHERE id = 1;
  DBMS_LOB.OPEN(l_blob, DBMS_LOB.LOB_READWRITE);
  

  此时另一个事务可以直接修改或删除该行：

  -- 事务2：修改该行并提交
  UPDATE t SET name = 'new_name' WHERE id = 1;
  COMMIT;
  -- 甚至直接删除
  DELETE FROM t WHERE id = 1;
  COMMIT;
  

  当事务1再用定位器写入BLOB时，要么因为基表行已被删除报错，要么写入的BLOB会关联到已被修改的行，破坏数据一致性——比如事务2更新了普通列，事务1写入的BLOB其实对应旧的业务逻辑，但行已经被修改，导致业务数据不匹配。

• LOB数据并发写入冲突，导致数据损坏或报错
  多个事务同时用定位器写入同一个BLOB时，由于没有行锁，Oracle不会阻止这种并发操作。最终可能出现：

  • 不同事务的写入内容互相覆盖，导致BLOB数据混乱（比如A写了前100字节，B写了后100字节，最终结果是两者的混合，但不符合任何一方的业务预期）
  • 触发ORA-22922: 不存在锁定的 LOB或ORA-22923: 指定的输入定位器无效等错误，因为LOB的版本已被其他事务修改。

• 读一致性机制失效，导致逻辑错误
  文档说打开定位器后保持读一致性，指的是定位器本身会指向打开时的LOB版本，但这只保证你读取的是快照数据，不阻止其他事务修改基表行或LOB本身。如果其他事务修改基表行并提交，基表行中的LOB指针会指向新的LOB版本，此时你再用旧定位器写入，会直接覆盖新的LOB数据——这完全违背了读一致性的预期，因为你的写入操作破坏了其他事务的修改结果。

正确的锁行方式 #

通常可以用SELECT ... FOR UPDATE获取定位器时直接锁行：

SELECT blob_col INTO l_blob FROM t WHERE id = 1 FOR UPDATE;

这样既能拿到定位器，又能锁定基表行，阻止其他事务对该行的任何DML操作，避免上述所有风险。

内容的提问来源于stack exchange，提问作者ABu