SQL触发器作为依附于表操作的自动执行逻辑，其性能表现会直接关联到对应写操作的耗时。当触发器出现性能抖动时，往往表现为同一类写操作的耗时突然升高，排查这类问题需要依赖准确的执行统计信息采集和持续的监控机制。
SQL触发器性能抖动的常见原因
触发器的性能抖动通常不是无缘无故出现的，常见的诱因主要有以下几类：
- 逻辑复杂度变化：触发器内部嵌套了多表关联查询、游标操作或者循环逻辑，当关联表的数据量增长后，执行耗时会出现明显波动。
- 统计信息过期：数据库优化器依赖表的统计信息生成执行计划，如果触发器关联的表统计信息长期未更新，可能导致执行计划走偏，引发性能抖动。
- 锁竞争加剧：触发器执行过程中如果涉及多行数据修改，可能会和其他事务产生锁等待，等待时间的不确定性会造成性能波动。
- 资源瓶颈：数据库服务器的CPU、内存或者IO资源出现临时不足时，触发器的执行耗时也会随之升高。
采集查询执行统计信息的方法
不同数据库提供了不同的系统视图和函数来采集触发器的执行统计信息，下面分别介绍MySQL和SQL Server的实现方式。
MySQL场景下的采集方法
MySQL可以通过查询performance_schema下的相关表获取触发器的执行统计，首先需要开启对应的采集项：
-- 开启performance_schema的语句统计采集
UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME = 'events_statements_history_long';
-- 查询触发器的执行统计信息，需要关联触发器定义和语句执行记录
SELECT
t.TRIGGER_NAME,
t.EVENT_MANIPULATION,
t.EVENT_OBJECT_TABLE,
es.COUNT_STAR AS 执行次数,
es.SUM_TIMER_WAIT/1000000000 AS 总耗时_秒,
es.AVG_TIMER_WAIT/1000000000 AS 平均耗时_秒,
es.MAX_TIMER_WAIT/1000000000 AS 最大耗时_秒
FROM information_schema.TRIGGERS t
JOIN performance_schema.events_statements_summary_by_digest es
ON es.DIGEST_TEXT LIKE CONCAT('%', UPPER(t.ACTION_STATEMENT), '%')
WHERE t.TRIGGER_SCHEMA = 'your_database_name'; -- 替换为实际数据库名
如果需要采集单次执行的详细统计，可以查询events_statements_history表，获取每次触发器执行的具体耗时、扫描行数等信息。
SQL Server场景下的采集方法
SQL Server可以通过系统动态管理视图sys.dm_exec_trigger_stats直接获取触发器的执行统计：
-- 查询所有触发器的执行统计信息
SELECT
t.name AS 触发器名称,
OBJECT_NAME(t.parent_id) AS 关联表名,
ts.execution_count AS 执行次数,
ts.total_elapsed_time/1000.0 AS 总耗时_毫秒,
ts.total_elapsed_time/1000.0/ts.execution_count AS 平均耗时_毫秒,
ts.max_elapsed_time/1000.0 AS 最大耗时_毫秒,
ts.total_logical_reads AS 总逻辑读次数,
ts.total_physical_reads AS 总物理读次数
FROM sys.triggers t
JOIN sys.dm_exec_trigger_stats ts
ON t.object_id = ts.object_id
ORDER BY ts.total_elapsed_time DESC;
如果需要更细粒度的单次执行信息，可以开启SQL Server的查询存储功能，或者配合使用扩展事件采集触发器执行的详细上下文。
持续监控触发器性能的方案
单次采集统计信息只能看到某个时间点的状态，要发现性能抖动需要建立持续的监控机制：
定期采集统计信息
可以编写定时脚本，每隔固定时间（比如5分钟）采集一次触发器的执行统计，将结果存入专门的监控表，方便后续对比分析：
-- MySQL场景下的定时采集表示例
CREATE TABLE IF NOT EXISTS trigger_perf_monitor (
id INT PRIMARY KEY AUTO_INCREMENT,
trigger_name VARCHAR(100),
db_name VARCHAR(100),
exec_count BIGINT,
avg_time_sec DECIMAL(10,4),
max_time_sec DECIMAL(10,4),
collect_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- 插入采集数据的存储过程
DELIMITER //
CREATE PROCEDURE collect_trigger_perf()
BEGIN
INSERT INTO trigger_perf_monitor (trigger_name, db_name, exec_count, avg_time_sec, max_time_sec)
SELECT
t.TRIGGER_NAME,
t.TRIGGER_SCHEMA,
es.COUNT_STAR,
es.AVG_TIMER_WAIT/1000000000,
es.MAX_TIMER_WAIT/1000000000
FROM information_schema.TRIGGERS t
JOIN performance_schema.events_statements_summary_by_digest es
ON es.DIGEST_TEXT LIKE CONCAT('%', UPPER(t.ACTION_STATEMENT), '%');
END //
DELIMITER ;
-- 可以用事件调度器定期执行，比如每5分钟执行一次
CREATE EVENT IF NOT EXISTS collect_trigger_perf_event
ON SCHEDULE EVERY 5 MINUTE
DO CALL collect_trigger_perf();
设置性能抖动告警阈值
基于采集到的历史数据，可以计算触发器耗时的一般范围，当平均耗时或者最大耗时超过阈值的一定比例（比如超过历史均值的2倍）时，触发告警通知运维人员。
关联业务操作分析
监控时需要同时记录触发器的执行时间和对应的业务操作时间，当发现性能抖动时，可以关联查看同一时间段的数据库负载、业务流量情况，快速定位抖动的根因。
优化建议
当通过监控发现触发器存在性能抖动后，可以参考以下方向优化：
- 简化触发器逻辑，避免在触发器内部执行复杂的多表关联或者批量操作，尽量将非必要的逻辑移到业务层处理。
- 定期更新触发器关联表的统计信息，保证数据库优化器可以生成最优的执行计划。
- 检查触发器的执行逻辑是否存在不必要的锁持有，尽量缩短触发器的执行时间，减少锁竞争的概率。
- 如果触发器的执行频率非常高，可以考虑将其逻辑改为异步处理，避免阻塞主业务的写操作。