概述
在工作中，我遇到过对表执行 dml 语句时出现持续长时间死锁的情况。在这种情况下，我使用轻量级 T-SQL 查询来查找死锁，即SQL 连接的阻塞和阻塞会话 ID。根据该语句返回的详细信息，我能够找到执行阻塞会话的应用程序或用户，并帮助我终止特定的 SQL 连接。它还帮助我们识别并修复频繁阻塞的 SQL 语句。
死锁产生的原因
多个并发事务同时访问数据库资源，而这些事务需要访问的资源（如表、行、页等）相互冲突，从而导致彼此互相等待，形成死锁。具体来说，当一个事务正在访问某些资源时，会对这些资源进行加锁以保证数据的一致性。如果另一个事务也要访问这些资源，但是由于锁的存在而无法访问，那么它就会被阻塞并等待锁释放。而如果两个或多个事务都互相持有对方需要的锁，那么它们就会陷入相互等待的状态，无法向前执行，形成死锁。
SQL Server死锁产生的场景包括但不限于以下几种情况：
- 并发事务更新相同的数据行或页
- 并发事务以不同的顺序获取锁
- 并发事务在执行过程中出现了阻塞或超时等异常情况
- 并发事务使用不同的隔离级别，例如一个事务使用了“读已提交”隔离级别，而另一个事务使用了“可重复读”隔离级别
如何发现死锁
为了避免死锁的产生，可以采用以下几种方法：
- 尽可能缩短事务的执行时间
- 减少事务中对资源的锁定时间
- 使用较低的隔离级别
- 对并发访问频繁的资源进行分区
- 监控并发事务的运行情况，及时发现并解决死锁问题。
监控并发事务的运行情况，是及时发现死锁的重要的手段，也是我们工作中最常用的手段。
下面是我用来快速查找死锁的查询。该语句基于SYS.DM_EXEC_REQUESTS动态管理视图。在此语句中，blocking_session_id列为您提供阻塞连接的 session_id，wait_type 列为您提供导致死锁的等待类型。获取blocking_session_id后，您可以使用另一个dmv SYS.DM_EXEC_SESSIONS来获取有关会话或连接的更多详细信息。
SELECT
session_id,
start_time,
[status],
command,
blocking_session_id,
wait_type,
wait_time,
open_transaction_count,
transaction_id,
total_elapsed_time,
Definition = CAST(text AS VARCHAR(MAX))
FROM
SYS.DM_EXEC_REQUESTS
CROSS APPLY sys.dm_exec_sql_text(sql_handle)
WHERE blocking_session_id != 0
