在数据库的应用系统中，死锁是不可避免的。通过设置死锁的处理优先级方法，可以在数据库引擎中自动检测到死锁，对发生的死锁会话进行干预，从而达到解除死锁的目点，但在这种情况下，会话只能被动的等待数据库引擎的自我检查。
我们是否可以让会话自身也拥有处理死锁的主动权呢？这就是设置锁的超时时间。当一个会话与另一个会话冲突引阻塞时，如果等待的时间超过指定的值，则该会话自动取消，并释放数据库资源。这样，就达到了解决死锁的目的。
那么如何来查看锁的超时时间呢?利用@@lock_timeout函数即可： 可以看一下@@LOCK_TIMEOUT的语法与定义：
@@LOCK_TIMEOUT--返回当前会话的当前锁超时设置，单位为毫秒。
返回类型--integer
解释说明： SET LOCK_TIMEOUT 允许应用程序设置语句等待阻塞资源的最长时间。当一条语句已等待超过LOCK_TIMEOUT所设置的时间，则被锁住的语句将自动取消，并给应用程序返回一条错误信息。
比如，我们要查看一个会话的超时时间，可以利用以下sql来查看：
select @@LOCK_TIMEOUT
在没有设置过超时时间的情况下，该语句会返回结果-1,代表没有超时时间。
那么又如何设置超时时间呢？可以利用以下sql语句：
set lock_timeout <锁超时时间 >
注意： 1，锁超时时间是以毫秒为单位的。 2，设置的超时时间只对当次会话有效。 可以做一个简单的测试，在microsoft sql server management中打开一个查询窗口，执行
set lock_timeout 2600 select @@lock_timeout
可以看到返回结果为2600毫秒，然后再打开一个新的查询窗口(即一个新的会话)，执行
select @@lock_timeout
返回结果为-1，可见前一个会话的设置对当前的会话无效。
如果将锁超时间设置为0，那么在发生资源锁定时，会话将不做任何等待，直接返回1222错误。
使用锁超时的不足之处： 如果我们有设置了锁超时时间，那么当会话等待时间达到超时时间时，就会直接返回1222错误，而且不会回滚或取消当前事务。需要我们在应用程序中截获1222错误，再作相关处理。如果我们在应用程序中未做任何处理，则事务会继续运行，从而导致程序的逻辑错误，因为前面有的语句可能根本没有执行或未执行完整。