如何查看MySQL触发器执行耗时

MySQL触发器执行耗时无法通过slow_query_log查看，因其只记录主DML语句而不捕获触发器内部SQL；需用performance_schema（≥5.6）开启对应消费者和仪器后查询events_statements_history_long表，或在触发器内加时间戳打点到诊断表，或直接禁用/启用触发器对比耗时差异。

MySQL 触发器执行耗时根本查不到 slow_query_log

slow_query_log 只记录主 DML 语句（如 INSERT INTO orders），不记录触发器内部执行的 SQL。哪怕触发器里跑了 3 秒的 SELECT COUNT(*) FROM huge_log_table，慢日志里也完全没痕迹——你看到的“0.02 秒”，只是表层快，真实耗时被掩盖了。

用 performance_schema 抓触发器真实耗时（MySQL ≥ 5.6）

这是目前最可靠、无需改代码的方式，但必须手动开启对应消费者和仪器：

1. 先确认已启用：SELECT @@performance_schema; 返回 1 才有效
2. 启用关键消费者：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_history_long', 'events_stages_history');
3. 启用语句计时：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/sql/%';
4. 执行一次带触发器的 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 才是秒）

在触发器里加时间戳打点（临时排查最直接）

适合快速验证某几个关键触发器是否拖慢写入，不依赖全局配置，但别长期开着：

1. 建轻量诊断表：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);
2. 在触发器开头插入起始时间：INSERT INTO trigger_debug_log (trigger_name, start_time, conn_id) VALUES ('tr_users_after_insert', NOW(6), CONNECTION_ID());
3. 结尾补结束时间与耗时（需用变量承接）：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;
4. 缺点：每次触发多两次 INSERT，高并发下会反向加重写入压力

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

这是最不可辩驳的验证方式，尤其适合批量操作或压测场景：

1. MySQL 8.0.19+ 支持：ALTER TABLE your_table DISABLE TRIGGER tr_name;，执行同一批 DML，记下耗时；再 ENABLE TRIGGER 重跑一次
2. MySQL DROP TRIGGER tr_name; → 记录耗时 → CREATE TRIGGER ...
3. 注意：禁用期间业务逻辑可能出错，务必在低峰或测试环境操作
4. 如果耗时差值显著（比如从 50ms 涨到 320ms），说明触发器确实是瓶颈，下一步才值得深挖内部语句

真正卡住的往往不是触发器语法本身，而是它同步执行的那条没走索引的 SELECT，或者锁表的 UPDATE——这些细节，只有打点或 performance_schema 能暴露出来。