必须启用sp:stmtcompleted事件并取消“仅收集客户端api调用”过滤，否则触发器内语句（如select、游标）完全不被捕获；推荐改用extended events监听sp_statement_completed(object_type='tr')精准追踪。
触发器语句不被Profiler捕获，怎么办？
SQL Server Profiler 默认只记录 INSERT/UPDATE/DELETE 主语句，完全忽略触发器内部执行的 SELECT、UPDATE 或游标逻辑。你看到“主语句耗时 60ms”，实际 58ms 花在触发器里——这正是 CPU 飙升却找不到元凶的最常见原因。
必须手动启用以下事件并关闭过滤：
- 勾选
SP:StmtCompleted（不是SP:Completed），它能捕获触发器内每一行语句的完成事件 - 取消勾选“仅收集客户端 API 调用”，否则所有触发器语句都会被过滤掉
- 若触发器内调用存储过程，额外勾选
RPC:Completed - 务必勾选“显示所有数据库”和“显示所有用户进程”
Extended Events 中如何精准抓取触发器执行？
Profiler 在高并发下自身开销大、易丢事件；Extended Events 是更轻量可靠的替代方案，但默认模板不包含触发器语句级追踪。必须显式过滤 object_type = 'TR'，否则日志爆炸且无法聚焦。
推荐用 T-SQL 创建会话（比 GUI 更稳定）：
CREATE EVENT SESSION [TraceTriggers] ON SERVER
ADD EVENT sqlserver.sp_statement_completed(
WHERE ([object_type] = 'TR')
)
ADD TARGET package0.event_file(SET filename=N'TraceTriggers.xel');
启动后，用 SSMS 打开 .xel 文件，筛选 sqlserver.sp_statement_completed 事件，重点关注 cpu_time 和 logical_reads 字段高的语句。
触发器里哪些写法最容易导致CPU飙升？
触发器是同步执行的，主 DML 必须等它全部跑完才能提交。一旦内部出现低效操作，就会把单线程 CPU 拉满，同时拖长锁持有时间，引发连锁阻塞。
-
SELECT * FROM inserted后直接JOIN大表：inserted表无索引，大结果集下全表扫描反复执行 - 用
DECLARE CURSOR遍历inserted：每行触发一次查询或计算，N 行 = N 次 CPU 消耗 - 在触发器中调用标量函数（如
dbo.fn_GetStatus()）：每行调用一次，等于 N 次编译 + 执行 -
UPDATE ... WHERE id IN (SELECT id FROM inserted)：未强制哈希匹配，优化器可能选择嵌套循环 + 索引查找，逻辑读暴增
验证方法：在 SSMS 中用 SET STATISTICS XML ON 执行触发器逻辑，看执行计划里是否有“表扫描”图标或“警告：缺少统计信息”提示。
怎么确认是触发器而不是其他原因导致CPU高？
不能只靠“看起来像”，得用数据交叉验证。先排除干扰项，再锁定触发器：
- 查
sys.dm_exec_trigger_stats：看total_cpu_time是否显著高于其他触发器，或是否近期突增 - 对比
sys.dm_exec_query_stats中高 CPU 查询：如果 top 5 里多个都关联同一张表，且该表有AFTER触发器，嫌疑极大 - 临时禁用触发器（仅限非生产验证）：
DISABLE TRIGGER TR_YourTable ON YourTable，观察 CPU 是否回落；注意必须在事务外执行，且评估业务影响 - 检查
SQLServer:SQL Statistics\SQL Compilations/sec：如果该值同步飙升，说明触发器内存在参数化不良或频繁重编译问题
真正容易被忽略的是：触发器本身没变，但 inserted 行数从几十暴涨到上万——数据量突变会让原本“还凑合”的写法瞬间崩盘。所以一定要结合业务变更和数据分布变化一起看。
