Kill会话
通过3.2中提到的系统存储过程可以获取到与死锁相关的信息。可以查询其中是哪个spid导致的死锁，并使用Kill spid的方法把它干掉。但是这只能是一种临时的解决方案，我们不可能一遇到死锁就在用户的生产环境里排查死锁、Killsp。同样的道理，也不可能一遇到死锁就重启SQL Server服务，甚至重启数据库服务器。
SQL脚本：
Kill 54; --此处54即分析后得到的spid值
sqlserver查看锁及解锁
查看被锁表：
select request_session_id spid,OBJECT_NAME(resource_associated_entity_id) tableName
from sys.dm_tran_locks where resource_type='OBJECT'
spid 锁表进程
tableName 被锁表名
解锁：
declare @spid int
Set @spid = 71--锁表进程
declare @sql varchar(1000)
set @sql='kill '+cast(@spid as v
设定锁请求超时
默认情况下，数据库没有锁定超时期限。也就是说一个会话在申请新的资源时，如果这个资源已经被其它进程锁定，那么本会话会一直处于等待状态。这样无疑是有问题的。我们可以通过SQL命令来设定锁请求超时。也可以访问全局变量 @@LOCK_TIMEOUT 来查看这个值。
SET LOCK_TIMEOUT 20000; --单位是毫秒
Isolation 属性一共支持五种事务设置，具体介绍如下：
（1）DEFAULT
使用数据库设置的隔离级别（默认），由DBA 默认的设置来决定隔离级别。
（2）READ_UNCOMMITTED
这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。
会出现脏读、不可重复读、幻读 （隔离级别最低，并发性能高）。
（3）READ_COMMITTED
保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。
可以避免脏读，但会出现不可重复读、幻读问题（锁定正在读取的行）。
（4）REPEATABLE_READ
可以防止脏读、不可重复读，但会出幻读（锁定所读取的所有行）。
（5）SERIALIZABLE
这是花费最高代价但是最可靠的事务隔离级别，事务被处理为顺序执行。
保证所有的情况不会发生（锁表）。
SET DEADLOCK_PRIORITY LOW
最大限度的降低死锁：
a）按同一顺序访问对象；
b）避免事务中的用户交互，也就是在事务执行过程中不要包含用户交互的步骤；
c）保持事务简短并在一个批处理中；
d）SELECT语句加WITH(NOLOCK)提示；
