SQL触发器不影响主语句执行计划，不会出现在EXPLAIN中；其真实开销需通过SHOW PROFILES、慢日志或performance_schema单独排查，内部SQL须手动EXPLAIN分析。
SQL触发器对主语句的执行计划完全没有影响——它根本不会出现在EXPLAIN输出里，也不参与优化器决策。
EXPLAIN结果里为什么找不到Trigger节点
MySQL、Oracle、SQL Server 的 EXPLAIN 或执行计划图形界面均不显示触发器。这不是你漏看了，是设计如此：触发器属于语句执行前/后的附加逻辑，由存储引擎或PL/SQL/T-SQL引擎同步调用，不在查询优化器（CBO、Cost-Based Optimizer）的规划范围内。
常见错误现象：EXPLAIN 显示 type: const、Using index，但实际执行慢得离谱；你反复调优主SQL索引，问题依旧——真凶大概率藏在触发器里。
- MySQL 的
EXPLAIN FORMAT=JSON输出中，query_plan字段只描述主DML语句，不含任何触发器内SQL - Oracle 的
DBMS_XPLAN.DISPLAY_CURSOR不会出现Trigger相关行 - SQL Server 图形执行计划里搜索不到
Triggers标签，哪怕表上有10个AFTER UPDATE触发器
触发器的真实开销怎么查
不能靠 EXPLAIN，必须换方式抓“隐藏耗时”：
- 用
SHOW PROFILES查整条语句总耗时，再禁用触发器重跑对比差值 - 开启慢日志：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0;，触发器内SQL会单独记录（需log_output='TABLE'或文件模式） - MySQL 8.0+ 查
performance_schema.events_statements_history_long，过滤EVENT_NAME LIKE '%trigger%'找出具体哪条子语句卡住 - SQL Server 开启
SET STATISTICS XML ON，解析XML里<RelOp PhysicalOp="Table Scan">这类节点——它们往往来自触发器内的SELECT
触发器里SQL的执行计划要单独EXPLAIN
触发器内部的每一条 SELECT、UPDATE、INSERT 都有自己的执行计划，但这个计划和主语句无关，必须手动提取出来单独分析：
- 把触发器里的SQL复制出来，加
EXPLAIN前缀运行，重点看type是否为ALL、key是否为空、Extra是否含Using temporary或Using filesort - 检查WHERE条件字段是否有索引，特别注意隐式类型转换：比如
user_id是BIGINT，但触发器里写成WHERE user_id = NEW.id，而NEW.id是INT，索引就失效 - 避免在触发器里写
SELECT COUNT(*) FROM logs WHERE status = 'pending'这类无索引条件的全表扫描——批量操作时会被放大N倍
为什么“IF分支多”不是缓存问题而是解析开销
MySQL 触发器里的 IF、ELSEIF 不走优化器，也没有执行计划缓存（8.0+ 已移除 query cache），每次都是逐行解释执行：
- 每层
IF都要重新读取NEW.status、做NULL判断、类型推导、布尔求值，字段访问成本被批量操作放大 - 看到“同样SQL有时快有时慢”，不是缓存抖动，而是不同数据触发了不同分支路径（比如某次走了4层嵌套，某次
RETURN提前退出） - 监控点不在
plan_cache_hits，而在performance_schema.events_statements_summary_by_digest中TRIGGER类型事件的avg_timer_wait
真正容易被忽略的是：触发器内SQL的性能问题永远藏在主语句的EXPLAIN之外，而它的锁、WAL、CPU开销却实打实地拖慢整个事务。别指望优化器帮你发现它——你得亲手把它从主语句里“剥”出来，单独测、单独EXPLAIN、单独加索引。
