SQL：查找被锁的表，以及锁表的SQL语句（重点推荐）

--死锁检测
use master
Select * from sysprocesses where blocked<>
--找到SPID
exec sp_lock
--根据SPID找到OBJID
select object_name()
--根据OBJID找到表名

1.DatabaseName 同于你要监测的数据库名(不过这个好像不起作用,我的电脑上设置无效)
2.DatabaseID 同于你要检测的数据库的dbid,可以用 selectdb_id(N'你要监测的库名')得到dbid
3.ObjectName 同于你要监测的对象名,例如表名,视图名等
4.ObjectID 同于你要监测的对象的id,可以用 select object_id(N'你要监测的对象名')得到id
5.Error 同于错误,如果经常出现某个编号的错误,则针对此错误号
6.Seccess 同于0,失败,1,成功,如果是排错,就过滤掉成功的处理

select db_id(N'ChinaHNDB_2013') --得到dbid
select object_name() 

 //*****************以下为SQL进行跟踪，并得到跟踪日志，再结合SQL Server Profiler 分析 *******************************

declare @rc int 
declare @TraceID int 
declare @FileName sysname
declare @maxfilesize bigint 
set @maxfilesize = 5  
SELECT @FileName = 'E:\lock2'

-- 初始化跟踪 
exec @rc = sp_trace_create @TraceID output, 0, @FileName, @maxfilesize, NULL  
--此处的e:/dblog/deadlockdetect是文件名（可自行修改），SQL会自动在后面加上.trc的扩展名 
if (@rc != 0) goto error

-- 设置跟踪事件 
declare @on bit 
set @on = 1 
--下述语句中的148指的是locks:deadlock graph事件(参见sys.trace_events),12指的是spid列(参见sys.trace_columns) 
exec sp_trace_setevent @TraceID, 148, 12, @on   
exec sp_trace_setevent @TraceID, 148, 11, @on 
exec sp_trace_setevent @TraceID, 148, 4, @on 
exec sp_trace_setevent @TraceID, 148, 14, @on 
exec sp_trace_setevent @TraceID, 148, 26, @on 
exec sp_trace_setevent @TraceID, 148, 64, @on 
exec sp_trace_setevent @TraceID, 148, 1, @on

-- 启动跟踪 
exec sp_trace_setstatus @TraceID, 1

-- 记录下跟踪ID，以备后面使用 
select TraceID = @TraceID 
goto finish

error:  
select ErrorCode=@rc

finish:  
go

exec sp_trace_setstatus 2, 0
exec sp_trace_setstatus 2, 2

select * from fn_trace_gettable('E:\lock2.trc',1)

/*
如果要暂停上面的服务器端跟踪，可运行下面的语句：
exec sp_trace_setstatus 3, 0 --第一个参数表示TraceID,即步骤1中的输出参数。第二个参数表示将状态改为0，即暂停

如果要停止上面的服务器端跟踪，可运行下面的语句：
exec sp_trace_setstatus 3, 2 --第一个参数表示TraceID,即步骤1中的输出参数。第二个参数表示将状态改为2，即停止

对于上面生成的跟踪文件(e:/DbLog/deadlockdetect.trc),可通过两种方法查看：
1.
select * from fn_trace_gettable('e:/DbLog/deadlockdetect.trc',1)
结果中的TextData列即以XML的形式返回死锁的详细信息。

2.
在SQL Server Profiler中打开。
依次 进入Profiler -> 打开跟踪文件 ->选择e:/DbLog/deadlockdetect.trc，就可以看到以图形形式展现的死锁信息了。

//*****************************************************************************************************

方法二： 用SQL Server Profiler分析死锁（重点推荐，2014-4-3编辑）

1. 打开 SQL Server Management Studio >>工具 >> SQL Server Profiler

2.创建一个新的跟踪

3.在事件选择页中，先勾选显示所有事件，再选择“死锁图形”事件、 “锁定：死锁”和“锁定：死锁链” (Deadlock graph，Lock:Deadlock；Lock:Deadlock Chain )如下图所示：

，最后 取消其它默认事件选项((Deadlock graph，Lock:Deadlock；Lock:Deadlock Chain 以外事件) ，并运行。

4. 跟踪一段时间，事务执行中止结束，选择Deadlock graph，我们可以直观查看到事务之间发生死锁的原因：

上图的椭圆形有一个叉，表示事务被SQL Server选择为死锁牺牲品，如果我们把鼠标指针移动到该叉椭圆中会出现一个提示。被锁定Object 为Proc存储过程(可以根据ID ,select object_id(N'ID)

二个矩形框称为资源节点，它们代表的数据库对象，如表，行或索引。

由于事务A和B在拥有各自资源时试图获得对方资源的一个独占锁，使得进程相互等待对方释放资源从而导致死锁。

解决死锁

这里有几个方法可以帮助我们解决死锁问题。

优化查询

我们在写查询语句时，要考虑一下查询是否Join了没有必要的表？是否返回数据太多（太多的列或行）？查询是否执行表扫描？是否能通过调整查询次序来避免死锁？是否应该使用Join的地方使用了Left Join？Not In语句是否考虑周到？

我们在写查询语句可以根据以上准则来考虑查询是否应该做出优化。

慎用With(NoLock)

默认情况下SELECT语句会对查询到的资源加S锁(共享锁)，由于S锁与X锁(排他锁)不兼容，在加上With(NoLock)后，SELECT不对查询到的资源加锁(或者加Sch-S锁，Sch-S锁可以与任何锁兼容)；从而使得查询语句可以更好和其他语句并发执行，适用于表数据更新不频繁的情况。

也许有些人会提出质疑With(NoLock)，可能会导致脏读，首先我们要考虑查询的表是否频繁进行更新操作，而且是否要读回来的数据会被修改，所以衡量是否使用With(NoLock)还是要根据具体实际出发。

优化索引

是否有任何缺失或多余的索引？是否有任何重复的索引？

处理死锁

我们不能时刻都观察死锁的发生，但我们可以通过日志来记录系统发生的死锁，我们可以把系统的死锁错误写入到表中，从而方便分析死锁原因。

缓存

也许我们正在执行许多相同的查询非常频繁，如果我们把这些频繁的操作都放到Cache中，执行查询的次数将减少发生死锁的机会。我们可以在数据库的临时表或表，或内存，或磁盘上应用Cache，或是磁盘文件。