数据库产生阻塞（Blocking）的本质原因 ：SQL语句连续持有锁的时间过长 ，数目过多， 粒度过大。阻塞是事务隔离带来的副作用，它是不可避免的，而且是一个数据库系统常见的现象。 但是阻塞的时间和出现频率要控制在一定的范围内，阻塞持续的时间过长或阻塞出现过多（过于频繁），就会对数据库性能产生严重的影响。
很多时候，DBA需要知道数据库在出现性能问题时，有没有发生阻塞？ 什么时候开始的？发生在那个数据库上？ 阻塞发生在那些SQL语句之间？ 阻塞的时间有多长？ 阻塞发生的频率？ 阻塞有关的连接是从那些客户端应用发送来的？.......
如果我们能够知道这些具体信息，我们就能迅速定位问题，分析阻塞产生的原因， 从而找出出现性能问题的根本原因，并根据具体原因给出相应的解决方案（索引调整、优化SQL语句等）。
查看阻塞的方法比较多， 我在这篇博客MS SQL 日常维护管理常用脚本(二)里面提到查看阻塞的一些方法：
方法1：查看那个引起阻塞，查看blk不为0的记录，如果存在阻塞进程，则是该阻塞进程的会话 ID。否则该列为零。
EXEC sp_who active
方法2：查看那个引起阻塞，查看字段BlkBy，这个能够得到比sp_who更多的信息。
EXEC sp_who2 active
方法3：sp_lock 系统存储过程，报告有关锁的信息，但是不方便定位问题
方法4：sp_who_lock存储过程
方法5：右键服务器-选择“活动和监视器”，查看进程选项。注意“任务状态”字段。
方法6：右键服务名称-选择报表-标准报表-活动-所有正在阻塞的事务。
但是上面方法，例如像sp_who、 sp_who2，sp_who_lock等，都有或多或少的缺点：例如不能查看阻塞和被阻塞的SQL语句。不能从查看一段时间内阻塞发生的情况等；没有显示阻塞的时间....... 我们要实现下面功能：
1: 查看那个会话阻塞了那个会话
2：阻塞会话和被阻塞会话正在执行的SQL语句
3：被阻塞了多长时间
4：像客户端IP、Proagram_Name之类信息
5：阻塞发生的时间点
6：阻塞发生的频率
7：如果需要，应该通知相关开发人员，DBA不能啥事情都包揽是吧，那不还得累死，总得让开发人员员参与进来优化（有些问题就该他们解决），多了解一些系统运行的具体情况，有利于他们认识问题、解决问题。
8：需要的时候开启这项功能，不需要关闭这项功能
于是为了满足上述功能，有了下面SQL 语句
SELECT wt.blocking_session_id AS BlockingSessesionId
,sp.program_name AS ProgramName
,COALESCE(sp.LOGINAME, sp.nt_username) AS HostName
,ec1.client_net_address AS ClientIpAddress
,db.name AS DatabaseName
,wt.wait_type AS WaitType
,ec1.connect_time AS BlockingStartTime
,wt.WAIT_DURATION_MS/1000 AS WaitDuration
,ec1.session_id AS BlockedSessionId
,h1.TEXT AS BlockedSQLText
,h2.TEXT AS BlockingSQLText
以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索数据库
， 问题
， 阻塞
， 方法
， 语句
， 时间
， socketjava阻塞
， sp_who_lock
jquery_ajax阻塞
sql server 阻塞、sql server 阻塞进程、sql server 查询阻塞、sqlserver 阻塞、sql server 查看阻塞，以便于您获取更多的相关知识。