触发器本身无独立性能统计，其性能问题必须通过宿主DML语句定位：SQL Server应监控sys.dm_exec_requests中长时间运行的INSERT/UPDATE/DELETE请求，结合logical_reads、wait_type等指标分析；MySQL需启用performance_schema抓取触发器各阶段耗时；所有数据库均禁用在触发器中查询information_schema或performance_schema实时表，避免元数据锁阻塞。

触发器本身不慢，慢的是它被强制塞进事务主路径里同步执行——所有资源消耗都算在原始 INSERT/UPDATE/DELETE 头上，查触发器统计等于白查。

SQL Server：别查 sys.dm_exec_trigger_stats，去盯 sys.dm_exec_requests

SQL Server 的触发器没有独立 CPU、I/O 或逻辑读统计。sys.dm_exec_trigger_stats 只有 execution_count 和 last_execution_time，没法告诉你它拖慢了多少。真正该盯的是挂靠它的 DML 语句：

• 用 sys.dm_exec_requests 筛出长时间运行的请求：WHERE command IN ('INSERT', 'UPDATE', 'DELETE') AND total_elapsed_time > 500000（0.5 秒阈值，OLTP 建议更严）
• 通过 sql_handle 拿到完整语句文本，确认是否操作了带触发器的表
• 如果 logical_reads 高但 cpu_time 低，大概率是触发器里做了没索引的 JOIN 或全表扫描
• 搭配 sys.dm_exec_sessions 查 status = 'suspended' 和 wait_type，常见如 LCK_M_U 或 IO_COMPLETION，说明锁或 I/O 被触发器逻辑卡住

MySQL：靠 performance_schema 挖耗时，别信 SHOW PROFILE

SHOW PROFILE 已弃用，且对触发器完全无效——它只显示外层语句耗时，根本看不到触发器内部哪一行卡住。必须用 performance_schema 实时抓取：

• 先启用关键 consumer：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_history', 'events_stages_history');
• 执行 DML 后，查触发器内各阶段耗时：SELECT EVENT_NAME, TIMER_WAIT / 1000000000000.0 AS sec FROM performance_schema.events_stages_history WHERE NESTING_EVENT_ID IN (SELECT EVENT_ID FROM performance_schema.events_statements_history WHERE SQL_TEXT LIKE '%your_table%') ORDER BY TIMER_WAIT DESC LIMIT 5;
• TIMER_WAIT 单位是皮秒，记得除以 10^12 换算成秒，别误当毫秒
• 重点看 stage/sql/Executing triggers 和后续子阶段，比如 stage/sql/Sending data 如果异常长，说明触发器里 SELECT 扫描量过大

所有数据库共通陷阱：触发器里查系统表 = 主动加锁阻塞写入

在触发器里执行 SELECT COUNT(*) FROM information_schema.COLUMNS 或 SELECT * FROM performance_schema.events_waits_current，不是“有点慢”，而是直接在写入路径上埋雷：

• information_schema 表是动态视图，每次查询都要遍历内存结构、采集快照、校验权限；高并发下会锁元数据缓存，导致所有后续 INSERT/UPDATE 等待
• performance_schema 的实时等待事件表（如 events_waits_current）在写入高峰期反向读取，极易触发 mutex 竞争
• 现象是单行插入从 2ms 涨到 800ms，SHOW ENGINE INNODB STATUS 显示 waiting for table metadata lock
• 绝对禁用的操作：information_schema.PROCESSLIST、performance_schema.events_waits_current、sys.schema_table_statistics

监控真正有效的指标：看它挂靠的语句，而不是触发器本身

看到 sys.dm_exec_trigger_stats.execution_count 猛增，或 PerfMon 里 “Number of Triggers Fired” 上升，不等于系统变慢——轻量日志记录和拖垮系统的触发器，调用次数可能一样多。关键要看宿主语句是否同步恶化：

• SQL Server：Lock Waits/sec 突升 + Batch Requests/sec 下跌 → 触发器事务太长或锁粒度太粗
• MySQL：slow_query_log 里同一条 INSERT 出现频次增加，且 Rows_examined 异常高 → 触发器里没走索引的 SELECT 在放大扫描量
• 通用信号：应用端超时错误增多，但数据库没报错；sys.dm_exec_requests 或 pg_stat_activity 显示大量会话卡在同一个表的 UPDATE/INSERT 上
• 最可靠验证法：临时 DISABLE TRIGGER（SQL Server/PostgreSQL）或重命名表隔离（MySQL），再跑原操作——延迟消失，就坐实问题

触发器的“慢”从来不是孤立现象，它是事务上下文、锁继承、同步执行三者叠加的结果。监控时盯着触发器本身，就像修车时只看仪表盘故障灯，却不去掀引擎盖——真正要拆开看的，是它被绑进去的那条 INSERT 或 UPDATE。