Oracle、MySQL、SQL Server 的执行计划均不显示触发器节点，因其属于语句执行前/后的PL/SQL或T-SQL附加逻辑，不在CBO或查询优化器规划范围内；需通过禁用对比、单独EXPLAIN触发器内SQL、监控递归调用或事件时序等方式定位性能问题。
Oracle 中触发器不显示在
的执行计划里
Oracle 的
和
输出中，**根本不会出现 Trigger 相关节点**。这不是你漏看了，是 Oracle 执行计划机制本身就不把触发器纳入计划树——它只展示 SQL 语句本身的访问路径、连接、过滤等逻辑，而触发器属于“语句执行后/前的附加动作”，被归入 PL/SQL 引擎调度，不在 CBO（Cost-Based Optimizer）规划范围内。
所以如果你在
里没找到
行，不是配置错，是设计如此。想确认触发器是否被调用，得换方式。
MySQL 触发器执行开销只能靠
或慢日志间接捕获
MySQL 同样不把触发器展开进执行计划。它的
只针对主 SQL，对
或
触发的逻辑完全静默。但触发器里的 SQL 仍会走优化器，只是你无法从父语句的
看到它们。
触发器内含
？这条语句自己可单独
触发器里调用了存储函数？该函数内部的查询无法被外层
覆盖
用
查看整条语句总耗时，再对比去掉触发器后的耗时差值，是定位开销的最直接办法
开启
并设
，能捕获触发器内所有慢子语句（需 MySQL ≥5.6 且 log_output='TABLE' 或 'FILE'）
SQL Server 的图形执行计划里压根没有 Triggers 标签
SSMS 的“包括实际的执行计划”输出中，
不会出现任何名为 Triggers、Trigger Execution 或类似字样的运算符节点
。哪怕你在表上建了 10 个
触发器，执行计划图里也只显示
或
这类主操作。
真正的问题藏在背后：
触发器代码若含
或
，这些操作会以“隐藏子计划”形式执行，但不出现在图形界面中
用
获取 XML 执行计划，搜索
，可能发现额外的扫描节点——它们大概率来自触发器
更可靠的方式：在触发器开头加
，配合 Profiler 抓取事件时序，确认是否卡在触发器内
排查触发器性能陷阱的关键动作清单
别指望执行计划自动标出触发器瓶颈。必须主动切片验证：
禁用触发器（
），重跑原 SQL，对比逻辑读、执行时间变化
把触发器内容复制出来，手动替换
为具体值，单独
其中每条 DML
检查触发器是否循环调用自身（比如
里又
同一表），这类死循环不会报错，但会导致执行时间指数增长
Oracle 中注意
统计里的
：数值突增往往意味着触发器引发大量递归 SQL（如审计日志插入触发索引维护）
最常被忽略的一点：触发器里没写
或
是对的，但它运行在主事务上下文中——一旦触发器某条语句全表扫描，整个事务的锁范围和持续时间就同步放大。这点永远比“执行计划有没有显示它”更致命。
DBMS_XPLANEXPLAIN PLANdisplay_cursordisplay_cursor(... 'allstats last')TriggersSHOW PROFILESEXPLAINAFTER INSERTBEFORE UPDATEEXPLAININSERT INTO log_tableEXPLAINEXPLAINSHOW PROFILESslow_query_loglong_query_time=0AFTER UPDATEClustered Index UpdateTable InsertSELECTJOINSET STATISTICS XML ONRAISERROR('trig_start', 0, 1) WITH NOWAITALTER TABLE t DISABLE TRIGGER tr_nameNEW.columnEXPLAINAFTER UPDATEUPDATEAUTOTRACE ONrecursive callsCOMMITROLLBACK