触发器本身不参与执行计划生成
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看不到，但慢得明明白白。
