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）
这是目前最可靠、无需改代码的方式，但必须手动开启对应消费者和仪器：
- 先确认已启用：
SELECT @@performance_schema;返回 1 才有效 - 启用关键消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_history_long', 'events_stages_history'); - 启用语句计时：
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 DROP TRIGGER tr_name; → 记录耗时 →
CREATE TRIGGER ... - 注意：禁用期间业务逻辑可能出错，务必在低峰或测试环境操作
- 如果耗时差值显著（比如从 50ms 涨到 320ms），说明触发器确实是瓶颈，下一步才值得深挖内部语句
真正卡住的往往不是触发器语法本身，而是它同步执行的那条没走索引的 SELECT，或者锁表的 UPDATE——这些细节，只有打点或 performance_schema 能暴露出来。
