直接查sys.dm_exec_requests可实时定位卡住的UPDATE语句，重点关注status为running或suspended、command∈('UPDATE','INSERT','DELETE')且total_elapsed_time>500000ms的请求，结合sql_handle关联sys.dm_exec_sql_text获取完整语句，并通过query_hash聚合分析历史趋势以识别重复高耗时模式。
查 sys.dm_exec_requests 找卡住的 UPDATE
直接看正在跑的语句，别等它结束。SQL Server 不会把触发器或子查询单独计时，但 sys.dm_exec_requests 能实时抓到还没返回的 UPDATE 请求，且带完整耗时字段。
-
status = 'running'或'suspended'都要盯——后者常因锁等待或 I/O 卡住 - 重点筛
command IN ('UPDATE', 'INSERT', 'DELETE')，别只盯着sql_text里有没有 UPDATE 字样，有些是存储过程调用 -
total_elapsed_time > 500000（0.5 秒）在 OLTP 环境就该预警；超过 3000000（3 秒）基本可判定异常 - 用
sql_handle关联sys.dm_exec_sql_text()提取真实语句，注意statement_start_offset和statement_end_offset，否则可能截出半条 SQL
结合 sys.dm_exec_query_stats 看历史趋势
单次卡顿可能是偶发，但同一条 UPDATE 反复出现在高耗时 Top 列表里，说明逻辑或数据分布有硬伤。缓存里的统计值虽非实时，但能暴露模式。
- 按
query_hash聚合比按sql_handle更可靠——参数化后语句结构一致，就算@id = 123和@id = 456也会归为同一类 -
total_logical_reads / execution_count突增，大概率是 WHERE 条件没走索引，或触发器里做了无索引 JOIN - 如果
total_worker_time很低但total_elapsed_time很高，优先查锁（blocking_session_id）和磁盘延迟（wait_type LIKE 'PAGEIOLATCH_%'）
别信 PRINT，用 RAISERROR ... WITH NOWAIT 输出进度
UPDATE 本身不提供进度反馈，但如果你控制执行逻辑（比如分批 UPDATE），必须靠主动打点。PRINT 会被缓冲，根本看不到实时输出。
- 写法必须是：
RAISERROR(N'已更新 %d/%d 行', 0, 1, @done, @total) WITH NOWAIT；severity 0–10 才绕过缓冲 - 消息长度超 2048 字符会截断，数字变量务必显式转
CONVERT(nvarchar, @done)，别依赖隐式转换 - 上线前删掉或注释掉——每千行打一次还行，每行打一次会让 UPDATE 慢 30% 以上
- 客户端需启用
FireInfoMessageEventOnUserErrors = true（.NET）或等效设置，否则收不到这些消息
触发器拖慢 UPDATE？去查宿主语句，不是查触发器
SQL Server 根本不给触发器记 CPU、I/O 或执行时间。sys.dm_exec_trigger_stats 只有 execution_count 和 last_execution_time，没有 cpu_time 字段。所有资源消耗都算在它挂靠的 UPDATE 头上。
- 看到某张表的 UPDATE 耗时飙升，先确认它有没有触发器；有，就直接查这条 UPDATE 的
logical_reads和wait_type - 若
wait_type = 'LCK_M_U'且持续时间长，大概率是触发器里事务太长，或更新了另一张被高频读写的表 - 不要在触发器里再 UPDATE 同一张表——SQL Server 允许，但极易引发死锁或隐式递归，监控只会显示“一条 UPDATE 卡了 10 秒”，原因藏在触发器逻辑深处
sql_handle 和 plan_handle 对应上执行计划，再比对前后变更点。 
