在 MySQL 中，触发器的执行耗时通常无法直接通过 slow_query_log 查看。原因很明确：慢查询日志记录的是外层触发触发器的主 DML 语句，并不会把触发器内部执行的 SQL 单独拆分出来。更实用的排查方法，是使用 performance_schema（适用于 MySQL 5.6 及以上版本），先开启相关消费者和仪器，再查询 events_statements_history_long 表；或者在触发器内部增加时间戳打点，把执行信息写入诊断表；如果想更直观地判断触发器是否影响性能，也可以通过禁用/启用触发器，对比前后的整体执行耗时差异。

MySQL 触发器执行耗时为什么无法通过 slow_query_log 直接看到

slow_query_log 记录的只是最外层那条主 DML 语句，例如 INSERT INTO orders。至于 MySQL 触发器内部具体执行了哪些 SQL，它不会单独写入慢日志。换句话说，即使触发器中实际执行了一条耗时 3 秒的 SELECT COUNT(*) FROM huge_log_table，你在慢查询日志里通常也看不到对应的独立记录——最终显示出来的“0.02 秒”很可能只是表面数据，真正拖慢性能的时间已经被隐藏在触发器逻辑中了。

用 performance_schema 查看 MySQL 触发器真实执行耗时（MySQL ≥ 5.6）

这是目前排查 MySQL 触发器性能最可靠、也不需要修改业务代码的方法，但前提是需要手动开启对应的消费者和仪器：

• 先确认是否已启用：SELECT @@performance_schema; 返回 1 才说明可用
• 启用关键消费者：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_history_long', 'events_stages_history');
• 启用 SQL 语句计时：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/sql/%';
• 执行一次会触发触发器的 DML 操作（例如 INSERT INTO users）后，再查询：SELECT EVENT_NAME, TIMER_WAIT/1000000000000 AS sec FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%TRIGGER%' OR EVENT_NAME LIKE '%trigger%' ORDER BY TIMER_WAIT DESC LIMIT 5;（注意：这里的时间单位是皮秒，除以 10^12 后才是秒）

在触发器中增加时间戳打点（临时定位最直接）

这种方式适合快速验证某几个关键触发器是否明显拖慢写入性能，不依赖全局配置，临时排查时非常有效，但不建议长期启用：

• 先创建一个轻量级诊断表：CREATE TABLE trigger_debug_log (id BIGINT PRIMARY KEY AUTO_INCREMENT, trigger_name VARCHAR(64), start_time DATETIME(6), end_time DATETIME(6), duration_ms DECIMAL(10,3), conn_id INT);
• 在触发器开始位置写入起始时间：INSERT INTO trigger_debug_log (trigger_name, start_time, conn_id) VALUES ('tr_users_after_insert', NOW(6), CONNECTION_ID());
• 在结束位置补充结束时间和耗时（通常需要变量承接）：SET @start_id := LAST_INSERT_ID(); INSERT INTO trigger_debug_log (trigger_name, start_time, end_time, duration_ms, conn_id) SELECT 'tr_users_after_insert', NOW(6), NOW(6), TIMESTAMPDIFF(MICROSECOND, t.start_time, NOW(6))/1000, CONNECTION_ID() FROM trigger_debug_log t WHERE t.id = @start_id;
• 缺点也很明显：每次触发器执行都会额外产生两次 INSERT，在高并发场景下反而可能进一步增加写入压力

禁用触发器前后对比耗时（判断触发器是否真慢的黄金标准）

这是最直接、也最有说服力的验证手段，特别适合批量写入、性能压测或数据库调优场景：

• MySQL 8.0.19+ 支持：ALTER TABLE your_table DISABLE TRIGGER tr_name;，执行同一批 DML 后记录耗时；然后再 ENABLE TRIGGER 重新测试一次
• MySQL < 8.0.19 只能通过删除再重建实现：DROP TRIGGER tr_name; → 记录耗时 → CREATE TRIGGER ...
• 需要特别注意：禁用触发器期间，依赖触发器的业务逻辑可能失效，因此务必在业务低峰期或测试环境中操作
• 如果前后耗时差距非常明显（例如从 50ms 上升到 320ms），基本可以判断触发器就是性能瓶颈，接下来才有必要继续深入分析内部 SQL

很多时候，真正拖慢 MySQL 触发器执行速度的，并不是触发器语法本身，而是它同步执行的某条没有命中索引的 SELECT，或者会引发锁竞争的 UPDATE。而这些隐藏的性能问题，通常只有通过打点监控或 performance_schema 才能被准确发现。