SQL Server阻塞与死锁排查：sys.sysprocesses视图详解与应用

理解sys.sysprocesses核心字段

sys.sysprocesses 包含正在 SQL Server 实例上运行的进程相关信息，这些进程既可以是客户端发起的请求，也可以是系统内部的维护任务。为了有效利用该视图进行排查，需重点关注以下关键字段及其业务含义：

第1步：识别会话与控制线程

目的：区分数据库会话与操作系统线程。

• Spid：SQL Server 会话 ID，代表一个数据库连接或会话单元。
• Kpid：Windows 线程 ID，对应操作系统层面的处理线程。

第2步：分析阻塞与等待状态

目的：确定是否存在资源竞争及阻塞链路。

• Blocked：当前被阻塞的会话 ID。若为 Null，表示未被阻塞；若值为其他 Spid，则表明受该 ID 的会话影响。
• Waittype：当前连接的等待资源编号。0 或 Null 表示无需等待特定资源（即处于可运行状态）。
• Waittime：当前等待资源的累计时间（毫秒）。0 表示无等待。

第3步：查看事务与执行上下文

目的：了解进程的运行阶段及事务层级。

• Status：进程状态，常见值包括 running（正在执行批处理）、suspended（等待事件完成）、rollback（处理回滚）、background（后台任务）等。
• Open_tran：打开的事务个数。大于 1 通常暗示存在嵌套事务。
• Cmd：当前正在执行的命令类型。
• Last_batch：上次执行存储过程或 Execute 语句的时间。对于系统进程，则为 Sql Server 启动时间。
• Login_time：客户端登录服务器的时间点。

第4步：定位用户与环境信息

目的：追踪请求来源及应用标识。

• DBID：当前进程使用的数据库 ID，用于关联具体数据库。
• UID：执行命令的用户 ID。
• Loginame：登录名。
• Hostname：建立链接的客户端工作站名称。
• Program_name：应用程序名称，通常对应连接字符串中配置的 Application Name。
• Hostprocess：客户端工作站内发起连接的进程 ID。

实战应用：排查阻塞与死锁

通过上述字段组合，可以构建有效的监控逻辑来发现数据库异常。

第1步：检查数据库是否发生阻塞

入口：直接查询 sys.sysprocesses 视图。

动作：查找 blocked 字段不为 0 的记录。阻塞关系的判定依据如下：

1. 判断阻塞链：如果 SPID 53 的 blocked 字段值为 52，且 SPID 52 的 blocked 字段为 0（或 Null），则说明存在阻塞，SPID 53 正被 SPID 52 阻塞。SPID 52 即为阻塞源头（Blocking Head）。
2. 判断 I/O 等待：如果发现某个连接的 blocked 字段值等于它自己的 spid（例如 Spid 10 的 blocked 为 10），这通常说明该连接正在进行大量的磁盘读写操作，需要等待自身的 I/O 完成才能继续，这是一种特殊的“自我阻塞”现象。

第2步：查找链接所在的数据库

入口：获取可疑进程的 DBID。

动作：通过查询得到 dbid 后，可进一步关联系统库以获取具体的数据库名称：

Select name, dbid from master.sys.sysdatabases

完成状态：确认受阻影响的数据库范围，从而缩小排查的应用程序或事务范围。

第3步：综合分析与终止异常进程

在实际操作中，找到阻塞源头（Blocked=0 的父进程）后，可根据 Program_name 和 Loginame 判断是否为正常业务进程或异常脚本。若确认为死锁或长时间持有的异常事务，管理员可考虑使用 KILL <Spid> 命令终止该进程以解除阻塞，但需注意这可能对未提交的事务造成数据丢失风险，务必谨慎操作并做好备份。

总结

利用 sys.sysprocesses 可以快速透视 SQL Server 的内部运行状况。核心在于通过分析 Blocked 字段还原阻塞链条，利用 Waittype 识别资源争用类型，并结合 DBID 锁定目标数据库。虽然这是基于底层视图的传统排查方式，但对于理解 SQL Server 阻塞机制仍具有重要价值。以上就是利用 sys.sysprocesses 检查 SqlServer 的阻塞和死锁的详细内容，更多关于 SqlServer 性能优化的资料请关注本站其它相关文章！