应监控挂靠的DML语句而非触发器本身，因SQL Server不单独统计触发器的cpu_time、logical_reads等指标，所有资源消耗均归入宿主INSERT/UPDATE/DELETE语句；需通过sys.dm_exec_requests和sys.dm_exec_sql_text定位高耗时DML，并结合Extended Events捕获sp_statement_completed(object_type='TR')分析触发器内部性能。
别查触发器本身，去查它挂靠的 DML 语句
SQL Server 不给触发器单独记 cpu_time、logical_reads 或执行时间——sys.dm_exec_trigger_stats 只有 execution_count 和 last_execution_time。你盯着它看，等于在监控一个没有仪表盘的发动机。
触发器逻辑被内联编译进宿主语句（比如一条 UPDATE Orders），所有资源消耗都算在那条语句头上。所以真正要盯的是 DML 请求，不是触发器对象。
- 用
sys.dm_exec_requests筛出长时间运行的请求：command IN ('INSERT', 'UPDATE', 'DELETE')且total_elapsed_time > 500000（0.5 秒，OLTP 环境建议阈值） - 通过
sql_handle关联sys.dm_exec_sql_text提取完整 SQL，确认是否操作了带触发器的表 - 重点比对
logical_reads和cpu_time：如果前者高但后者低，大概率是触发器里做了没索引的 JOIN 或全表扫描
用 Extended Events 捕获触发器内部语句级耗时
Profiler 默认不展开触发器里的语句，只显示外层 DML，极易误判“主语句快，触发器慢”——实际 90% 耗时藏在触发器内部的 SELECT 或游标里。
必须用 Extended Events 捕获 sp_statement_completed 事件，并加 WHERE object_type = 'TR' 过滤，否则日志爆炸且难定位。
- 创建会话时，务必包含
sql_text、duration、cpu_time、logical_reads字段 - 避免用 GUI 模板，直接用 T-SQL 创建（更可控）：
CREATE EVENT SESSION [TriggerPerf] ON SERVER ADD EVENT sqlserver.sp_statement_completed(WHERE object_type = 'TR') - 不要依赖
SP:StmtCompleted在 Profiler 里勾选——Profiler 底层是 SQL Trace，高并发下自身开销大、易丢事件
检查 inserted/deleted 表是否引发隐式性能陷阱
触发器里直接对 inserted 或 deleted 表做 JOIN 或子查询，但它们没有索引，结果集一大就必然拖垮性能。
- 大结果集（>1000 行）务必先插入临时表：
SELECT * INTO #ins FROM inserted，再在#ins上建索引 - 避免写
UPDATE t SET x = y WHERE id IN (SELECT id FROM inserted)——没走哈希匹配时，等于对目标表反复全表扫描 - 禁用标量函数调用：
dbo.fn_GetStatus(id)在触发器里每行执行一次，N 行就是 N 次独立执行 - 用
SET STATISTICS XML ON在 SSMS 里单独跑触发器逻辑，重点看执行计划里有没有“表扫描”或黄色警告图标
从锁和事务行为反推触发器瓶颈
触发器同步执行，主 DML 必须等它结束才能提交。一旦它持锁时间长、事务范围大，就会引发连锁阻塞。
- 观察 PerfMon 计数器：
Lock Waits/sec突升 +Batch Requests/sec下跌，大概率是触发器里事务太长或锁粒度太粗 - 用
sys.dm_tran_locks查当前被锁资源，结合request_session_id回溯到sys.dm_exec_requests，确认是否来自带触发器的表操作 - 注意
AFTER触发器里再 UPDATE 同一张表——极易死锁；INSTEAD OF里递归调用自身也属高危设计，监控只是补救，重构才是解法
触发器的“最大消耗”往往不在它自己身上，而在它让主语句变慢、变重、变卡的方式里。最常被忽略的点是：你看到 sys.dm_exec_trigger_stats.execution_count 猛增，却没同步去看对应 DML 的 avg_logical_reads 是否同步跳涨——这两者不同步，说明触发器还没成为瓶颈；一旦同步恶化，问题就已落地生根。
