COMPOUND触发器不能解决行级锁冲突，仅规避ORA-04091变异表错误；行级锁由事务和DML语句决定，与触发器类型无关。
COMPOUND触发器本身不解决行级锁冲突，它只是帮你绕开“表正在变异”错误（ORA-04091）；真正的行级锁冲突得靠事务设计和DML顺序来控制。
为什么COMPOUND触发器常被误认为能“避免锁冲突”
很多人看到 COMPOUND TRIGGER 里把逻辑拆到 AFTER EACH ROW 和 AFTER STATEMENT，就以为它能减少锁持有时间或规避锁等待。其实不是：Oracle 对 DML 操作涉及的行加的行级锁（TX 锁），是在语句执行期间一直持有的，直到事务提交或回滚 —— 这和你用的是简单触发器还是复合触发器完全无关。
COMPOUND 触发器真正解决的是「读写冲突」类问题，比如在 BEFORE/AFTER ROW 中去查同一张表（SELECT ... FROM orders），触发 ORA-04091；它通过延迟聚合操作到语句级阶段，避开变异表限制，但不会让 UPDATE orders 的行锁变短、变少或可跳过。
COMPOUND触发器中哪些写法会意外延长锁持有时间
你在 AFTER STATEMENT 块里写的 SQL，只要没显式 COMMIT，就仍在原事务上下文中执行 —— 它会继续持有前面 DML 已获取的所有行锁。常见踩坑点：
- 在
AFTER STATEMENT里执行UPDATE blatranscript SET child_count = (SELECT COUNT(*) FROM blatchildren WHERE ...)，这个子查询如果扫描大量blatchildren行，可能引发额外锁争用，甚至死锁 - 用
FORALL i IN INDICES OF v_ids UPDATE ... WHERE id = v_ids(i)批量更新时，若v_ids顺序和主表 DML 的行物理顺序不一致，容易造成锁升级或等待链 - 在
AFTER STATEMENT调用另一个含 DML 的存储过程，而该过程又没设为AUTONOMOUS_TRANSACTION，等于把锁范围扩大到那个过程涉及的所有表
真正缓解行级锁冲突的实操建议
如果你的目标是降低高并发 UPDATE 场景下的锁等待，重点不在触发器类型，而在怎么组织事务和访问路径：
- 确保 WHERE 条件能走唯一索引（比如
WHERE order_id = :NEW.order_id），避免全表扫描带来的锁扩散 - 批量操作尽量按主键升序处理（例如排序后逐条 UPDATE），减少交叉锁等待概率
- 业务上允许的话，把原本分散在多个小事务里的 UPDATE 合并成单次大事务（前提是锁持有时间可控），比频繁开启/提交更轻量
- 对必须异步响应的场景，别在触发器里硬做耗时操作；改用
DBMS_ALERT或队列表 + 后台作业，让锁在主事务提交后才释放
一个典型但危险的“伪优化”示例
下面这段代码看似用了 COMPOUND 触发器，实际反而加重锁风险：
CREATE OR REPLACE TRIGGER tr_orders_audit FOR UPDATE ON orders COMPOUND TRIGGER TYPE t_order_ids IS TABLE OF orders.order_id%TYPE; l_ids t_order_ids := t_order_ids(); <p>AFTER EACH ROW IS BEGIN IF :NEW.status = 'SHIPPED' THEN l_ids.EXTEND; l_ids(l_ids.LAST) := :NEW.order_id; END IF; END AFTER EACH ROW;</p><p>AFTER STATEMENT IS BEGIN -- ⚠️ 危险：这里 UPDATE orders 本身，又去查 orders，还带子查询 UPDATE orders o SET last_shipped_at = SYSDATE WHERE o.order_id IN (SELECT COLUMN_VALUE FROM TABLE(l_ids)) AND EXISTS ( SELECT 1 FROM shipments s WHERE s.order_id = o.order_id AND s.status = 'SENT' ); END AFTER STATEMENT; END;
这个 AFTER STATEMENT 更新会再次锁定一批 orders 行，并且子查询可能触发对 shipments 的全索引扫描 —— 如果并发 UPDATE 很多，极易出现 TX 锁等待甚至死锁。真正该做的，是把这类逻辑抽离出触发器，交给应用层或调度作业。
复杂点在于：锁行为由 Oracle 底层事务机制决定，触发器只是执行环境；你写的每一条 SQL 在什么时刻加什么锁、持有多久，跟是否用了 COMPOUND 无关，只跟你写的语句本身、索引设计、事务边界有关。
