最准、最轻量的方式是查 sys.dm_exec_requests 关联 sys.dm_exec_sql_text，过滤 status IN ('running','suspended') 且 SQL 含 DELETE，用 DATEDIFF(second, start_time, GETDATE()) 计算已执行秒数并排序，可精准定位当前卡住的 DELETE 操作及阻塞源头。
直接查 sys.dm_exec_requests + sys.dm_exec_sql_text，过滤掉空闲会话和非 DELETE 语句，再按执行时间排序 —— 这是最准、最轻量的方式。
怎么快速定位正在运行的长时间 DELETE
别用 sp_who 或 sp_who2，它们不返回当前执行的 SQL 文本，也看不到执行时长。真正能抓到“正在跑的 DELETE”且带运行时间的，是 sys.dm_exec_requests 视图中的 start_time 和 status 字段。
-
status = 'running'表示当前正在 CPU 上执行（不是挂起或等待） -
command = 'DELETE'可初步筛选，但更可靠的是解析 SQL 文本 - 用
DATEDIFF(second, start_time, GETDATE())算出已执行秒数，避免依赖模糊的cpu_time或reads - 必须
CROSS APPLY sys.dm_exec_sql_text(sql_handle)才能看到实际语句，否则你连删的是哪张表都不知道
为什么不能只靠 sys.dm_exec_query_stats
这个 DMV 记录的是“已结束”查询的累计统计，total_elapsed_time 是历史总耗时，last_execution_time 是上一次执行完的时间 —— 它压根不包含“当前还在跑”的 DELETE。你用它查，结果永远为空或全是旧记录。
- 想看“正在发生什么”，必须用实时会话视图，不是历史聚合视图
-
sys.dm_exec_query_stats适合找“谁长期慢”，不适合抓“此刻卡在哪” - 它还可能因计划缓存清理而丢失近期执行过的语句，稳定性不如
sys.dm_exec_requests
一个可直接执行的诊断查询
下面这段 SQL 能立刻列出所有运行中、持续超 30 秒的 DELETE（含完整语句和阻塞关系）：
SELECT
r.session_id,
r.status,
r.command,
DATEDIFF(second, r.start_time, GETDATE()) AS [running_sec],
r.blocking_session_id,
t.text AS [sql_text],
SUBSTRING(t.text, (r.statement_start_offset/2)+1,
((CASE r.statement_end_offset WHEN -1 THEN DATALENGTH(t.text) ELSE r.statement_end_offset END - r.statement_start_offset)/2) + 1) AS [statement]
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.status = 'running'
AND t.text LIKE '%DELETE%'
AND DATEDIFF(second, r.start_time, GETDATE()) > 30
ORDER BY running_sec DESC;-
t.text LIKE '%DELETE%'比r.command = 'DELETE'更稳妥：有些 DELETE 可能被包装在存储过程中，command显示为EXECUTE -
SUBSTRING(...)部分提取的是实际执行的语句片段，不是整个批处理，对定位具体操作行更有效 - 如果
blocking_session_id > 0，说明它正被别的会话锁住，得顺藤摸瓜查源头
容易被忽略的关键点
真正卡住的 DELETE 往往不是语句本身慢，而是被锁住后一直 suspend 在那里 —— 此时它的 status 是 suspended，不是 running，上面的查询就漏掉了。
- 要覆盖这种场景，必须把
status IN ('running', 'suspended')都纳入，并加查wait_type（比如LCK_M_U就是典型的更新锁等待） - 长时间
suspended的 DELETE，start_time是它最初开始的时间，但真正卡住是从某次等待开始的，所以光看running_sec会误判 - 如果数据库启用了优化锁定（SQL Server 2023+），DELETE 的锁行为和内存占用会有变化，但阻塞链的排查逻辑不变
