触发器内子查询会逐行同步执行且无法优化，导致批量更新时性能崩溃；应改用预计算字段、物化视图或严格受限的单点主键查询。
别在触发器里写复杂子查询——它会在每行上同步执行 N 次，批量更新时直接卡死。Oracle 19c 的触发器是行级同步上下文，不支持自动解嵌套、谓词下推或并行化，所有子查询都会退化为逐行 FILTER 操作。
为什么触发器里的子查询比普通 SQL 更危险
普通 SQL 中的子查询至少还有优化器干预空间（比如 UNNEST 提示、物化选择）；而触发器内嵌的 SELECT 语句完全被锁定在行级执行生命周期里：
- BEFORE/AFTER 行级触发器中每出现一次
SELECT ... FROM big_table WHERE x = :NEW.y，就触发一次独立全表扫描或索引查找 - 子查询若含
MAX()、COUNT()、EXISTS或函数（如TRIM(:NEW.code)），Oracle 不会尝试重写，也不会下推外层条件 - 即使主表只更新 10 行，而子查询涉及百万行员工数据，也会执行 10 次完整聚合
-
NEW和OLD值无法被优化器提前绑定为常量，导致统计信息失效、Cardinality 估算严重偏差
替代方案：用预计算字段 + 应用层维护
把“查出来再判断”逻辑，改为“写进去就确定”——这是高并发下唯一可控路径：
- 在主表增加冗余字段，如
dept_total_salary，INSERT/UPDATE 时由应用层计算并显式赋值：NEW.dept_total_salary := OLD.dept_total_salary + NEW.salary - 避免在触发器中反查部门表求和；改由批处理任务每日凌晨刷新汇总值，并加
DBMS_SCHEDULER保证幂等 - 若必须数据库层闭环，用
MATERIALIZED VIEW固化结果，再让触发器只读取该物化视图（注意：物化视图不能在触发器内刷新） - 禁止在触发器中调用含子查询的存储过程——调用栈会放大延迟，且无法被
DBMS_PROFILER准确归因
实在要保留子查询？必须满足这三条硬约束
如果业务强依赖触发器内实时查关联表（例如风控拦截），只能收窄范围、堵死退路：
- 只允许单点主键查询：
SELECT status FROM user_config WHERE user_id = :NEW.user_id，且user_config(user_id)必须有 B-Tree 索引 - 禁用任何聚合、
DISTINCT、ROWNUM、ORDER BY，它们会强制物化中间结果，阻断索引访问路径 - 所有字段类型严格一致：比如
:NEW.deptno是NUMBER，子查询中dept.deptno也必须是NUMBER，否则隐式转换使索引失效
最易被忽略的是：触发器里的子查询没有执行计划缓存隔离——它复用主 DML 语句的游标，一旦主语句因绑定变量窥探选错计划，子查询也跟着一起崩。这不是调优问题，是架构约束。
