SQL存储过程如何查看当前阻塞会话？-SQL-PHP中文网

优先使用sys.dm_exec_requests，因其为实时dmv、字段语义清晰（如blocking_session_id），而sys.sysprocesses是已废弃的兼容视图；sp_who通过blk列、sp_who2通过blkby列可直接识别阻塞源，但均不返回sql文本，需配合dbcc inputbuffer或dm_exec_sql_text获取。

sql存储过程如何查看当前阻塞会话？

Flova

Flova是一款AI文本写作工具，全球首个一体化 AI 视频创作平台。

下载

查阻塞用 `sys.sysprocesses` 还是 `sys.dm_exec_requests`？

sys.sysprocesses 是兼容视图，SQL Server 2005+ 仍可查，但已废弃；sys.dm_exec_requests 是动态管理视图（DMV），实时性更好、字段更明确，推荐优先使用。 sys.sysprocesses 中的 blocked 字段值为 0 表示未被阻塞，非 0 则表示该 SPID 正被该值对应的 SPID 阻塞；而 sys.dm_exec_requests 用 blocking_session_id 字段替代，语义更清晰。注意：sys.dm_exec_requests 不包含已断开连接但事务未提交的“幽灵会话”，这类会话可能只在 sys.sysprocesses 或 sys.dm_tran_locks 中暴露。

`sp_who` 和 `sp_who2` 能直接看出谁在阻塞吗？

sp_who 返回结果中 blk 列即阻塞源 SPID，值为 0 表示未被阻塞，非 0 即阻塞者 ID；sp_who2 是扩展版，多出 BlkBy 列（等价于 blk），还带 CPU、MemUsage、Command 等实用字段。两者都不返回 SQL 文本，要查具体语句必须配合 DBCC INPUTBUFFER(spid) 或 sys.dm_exec_sql_text(sql_handle)。 sp_who2 无官方文档支持，属未公开系统存储过程，生产环境慎用；sp_who 官方支持，但仅限基础信息，不推荐用于深度诊断。

怎么一次性定位“头阻塞者”和它锁住的资源？

头阻塞者指 blocking_session_id = 0 且 status = 'suspended' 或 'running' 的活跃会话，同时自身没被别人堵。常用组合查询：

先筛出所有被阻塞的请求：SELECT session_id, blocking_session_id, wait_type, wait_resource FROM sys.dm_exec_requests WHERE blocking_session_id 0
再反查谁在阻塞它们：SELECT session_id, status, command, sql_handle FROM sys.dm_exec_requests WHERE session_id IN (SELECT DISTINCT blocking_session_id FROM sys.dm_exec_requests WHERE blocking_session_id 0) AND blocking_session_id = 0
最后看它持有哪些锁：SELECT resource_type, resource_description, request_mode, request_status FROM sys.dm_tran_locks WHERE request_session_id = @head_spid

wait_resource 值如 "KEY: 5:72057594044108800 (b52e3f0c6a0d)" 或 "OBJECT: 5:123456789" 可直接对应到 sys.dm_tran_locks 中的资源描述，这是判断锁粒度（行/页/表）的关键依据。

为什么 `KILL` 之后还会立刻再出现阻塞？

常见原因有三个： - 应用层没正确关闭连接，事务未提交或回滚，KILL 后重连又执行同样逻辑； - 查询本身缺乏索引，导致扫描全表或大量页，锁持有时间长，多个并发一上来就互等； - 启用了锁升级（默认阈值 5000 行锁），一个 UPDATE 触发了表级 X 锁，后续所有 SELECT/INSERT 都被拦住。验证锁升级是否发生：查 sys.dm_os_wait_stats 中 waiting_tasks_count 较高的 wait_type，如 LCK_M_SCH_M（架构修改锁）或持续出现的 LCK_M_X；再用扩展事件捕获 lock_escalation 事件。别只盯着 KILL，得看 last_batch 时间和 open_tran 数——如果 open_tran > 1 且 last_batch 是几小时前，基本就是应用端漏了 COMMIT/ROLLBACK。