触发器不参与执行计划生成，explain结果仅反映主sql语句本身；其性能开销真实存在但不可见于执行计划，需通过show profiles、单独explain触发器内sql等方式排查优化。
触发器本身不参与执行计划生成
MySQL 的 EXPLAIN 或 EXPLAIN FORMAT=JSON 输出只反映当前 SQL 语句本身的访问路径、连接顺序、索引选择等，**不会把触发器里的语句纳入执行计划分析范围**。触发器逻辑在语句执行完成（或回滚前）才被调用，属于“事后动作”，优化器根本看不到它。
这意味着：即使你在 INSERT 上定义了一个含复杂子查询的 BEFORE INSERT 触发器，EXPLAIN 显示的仍是原始 INSERT 的执行计划，和触发器无关。
但触发器会实质性拖慢 SQL 实际执行时间
虽然不改执行计划，触发器带来的开销是真实存在的，尤其在高并发或大数据量写入时：
-
BEFORE触发器中的计算、校验、赋值会阻塞主语句执行，直到它返回 -
AFTER触发器若包含INSERT/UPDATE/DELETE操作，会引发额外的行锁、日志写入、甚至二次触发（如没禁用SQL_LOG_BIN或未设innodb_lock_wait_timeout） - 触发器里调用存储函数或访问其他表时，可能产生隐式全表扫描（尤其没走索引），而这个慢操作不会出现在原语句的
EXPLAIN里
典型表现：一条 INSERT 语句 EXPLAIN 显示“Using index”，执行却耗时 800ms——真凶往往藏在 AFTER INSERT 触发器里的一次无索引 UPDATE t_log SET status=1 WHERE user_id = NEW.id AND type='pending'。
排查触发器导致性能问题的实操方法
不能靠 EXPLAIN，得换思路抓真凶：
- 用
SHOW PROFILES或performance_schema.events_statements_history_long查看完整执行链路，定位耗时最高的子语句 - 临时禁用触发器验证影响：
SET @disable_triggers = 1;（需在触发器逻辑里加判断）或直接DROP TRIGGER后重测 - 对触发器内 SQL 单独
EXPLAIN，重点检查WHERE条件列是否有对应索引，避免type: ALL - 确认是否启用了
log_bin_trust_function_creators，否则含非确定性函数的触发器可能被拒绝执行或降级为 row-based 复制，间接影响性能
触发器与执行计划优化的边界在哪
执行计划优化始终围绕“单条语句如何最快落地数据”，而触发器属于业务逻辑扩展层。两者不在同一抽象层级：
- 索引优化、JOIN 顺序调整、分区裁剪——这些对主 SQL 有效，对触发器无效
- 想让触发器快，必须单独优化它内部的每一条 SQL，包括加索引、拆分大事务、避免循环查表
- 如果触发器频繁更新同一张大表，考虑用异步队列（如 Kafka + 消费者）替代，彻底移出事务链路
最易被忽略的一点：触发器中引用的 NEW 或 OLD 字段，如果类型和目标表字段不一致（比如 NEW.id 是 INT，但触发器里拿来和 VARCHAR 字段比较），会引发隐式类型转换，导致索引失效——这种坑，EXPLAIN 看不到，但慢得明明白白。
