SQLSERVER 语句交错引发的死锁问题案例详解

更新时间：2023年02月21日 14:42:44 作者：一线码农

这篇文章主要介绍了SQLSERVER 语句交错引发的死锁研究,要解决死锁问题，个人感觉需要非常熟知各种隔离级别，尤其是可提交读模式下的 CURD 加解锁过程，这一篇我们就来好好聊一聊

一：背景

1. 讲故事

相信大家在使用 SQLSERVER 的过程中经常会遇到 阻塞 和 死锁，尤其是 死锁，比如下面的输出：

(1 row affected) Msg 1205, Level 13, State 51, Line 5 Transaction (Process ID 62) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

要解决死锁问题，个人感觉需要非常熟知各种隔离级别，尤其是 可提交读 模式下的 CURD 加解锁过程，这一篇我们就来好好聊一聊。

二：死锁简析

1. 一个测试案例

开启两个会话 65 和 66 ，分别使用如下查询。

-- 会话 65 --
BEGIN TRAN
UPDATE dbo.Employees SET Title='Dr.' WHERE EmployeeID=1;
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Orders WHERE OrderID=10258
ROLLBACK

-- 会话 66 --
BEGIN TRAN
UPDATE  dbo.Orders SET  ShipAddress='上海' WHERE OrderID=10258
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Employees WHERE EmployeeID=1;
ROLLBACK

两个会话非常简单，交错的对 Employees 和 Orders 进行 SELECT 和 UPDATE 操作，稍等几秒后就会出现死锁。

2. 寻找死锁源头

当我们的应用程序拿到了这样的输出其实作用是不大的，要想溯源最好就是通过不断的对 SQLSERVER 进行监视来捕获死锁时的上下文信息，手段也有很多：

SQL Server Profile
DBCC TRACEON(1222)
DMV VIEW

这里我们就用第一种方式，一定要勾选 TextData 项，因为这里面会有死锁上下文信息的xml表示，截图如下：

将 profile 开启后，重新执行刚才的两个查询，一旦出现死锁，profile 就会成功捕获，然后 copy 出 TextData 项，截图如下：

<deadlock-list>
 <deadlock victim="process2d69c9748c8">
  <process-list>
   <process id="process2d69c9748c8" taskpriority="0" logused="324" waitresource="KEY: 7:72057594043170816 (8194443284a0)" waittime="1304" ownerId="70740" transactionname="user_transaction" lasttranstarted="2023-02-19T22:11:26.413" XDES="0x2d6a0200428" lockMode="S" schedulerid="5" kpid="13816" status="suspended" spid="66" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2023-02-19T22:11:26.413" lastbatchcompleted="2023-02-19T22:11:26.410" lastattention="1900-01-01T00:00:00.410" clientapp="Microsoft SQL Server Management Studio - Query" hostname="DESKTOP-STS8TPB" hostpid="1696" loginname="DESKTOP-STS8TPB\Administrator" isolationlevel="read committed (2)" xactid="70740" currentdb="7" currentdbname="Northwind" lockTimeout="4294967295" clientoption1="671090784" clientoption2="390200">
    <executionStack>
     <frame procname="adhoc" line="5" stmtstart="24" stmtend="128" sqlhandle="0x020000007383d935b349bc173c0f104de14945e9a526322b0000000000000000000000000000000000000000">
unknown     </frame>
     <frame procname="adhoc" line="5" stmtstart="204" stmtend="294" sqlhandle="0x020000002c3b203105961d63d10b17e54ed6ac081105f9450000000000000000000000000000000000000000">
unknown     </frame>
    </executionStack>
    <inputbuf>

BEGIN TRAN
UPDATE  dbo.Orders SET  ShipAddress=&apos;上海&apos; WHERE OrderID=10258
WAITFOR DELAY &apos;00:00:10&apos;
SELECT * FROM dbo.Employees WHERE EmployeeID=1;
ROLLBACK
    </inputbuf>
   </process>
   <process id="process2d6ae694ca8" taskpriority="0" logused="368" waitresource="KEY: 7:72057594044088320 (59ce0997f9b8)" waittime="3468" ownerId="70716" transactionname="user_transaction" lasttranstarted="2023-02-19T22:11:24.247" XDES="0x2d6a7284428" lockMode="S" schedulerid="9" kpid="7124" status="suspended" spid="65" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2023-02-19T22:11:24.247" lastbatchcompleted="2023-02-19T22:11:24.247" lastattention="1900-01-01T00:00:00.247" clientapp="Microsoft SQL Server Management Studio - Query" hostname="DESKTOP-STS8TPB" hostpid="1696" loginname="DESKTOP-STS8TPB\Administrator" isolationlevel="read committed (2)" xactid="70716" currentdb="7" currentdbname="Northwind" lockTimeout="4294967295" clientoption1="671090784" clientoption2="390200">
    <executionStack>
     <frame procname="adhoc" line="5" stmtstart="26" stmtend="118" sqlhandle="0x02000000dd7720067e0519b8a368501716c04b4b50cfe6be0000000000000000000000000000000000000000">
unknown     </frame>
     <frame procname="adhoc" line="5" stmtstart="196" stmtend="282" sqlhandle="0x0200000093f01512208755a056f5f28930fbd3dedf58a2850000000000000000000000000000000000000000">
unknown     </frame>
    </executionStack>
    <inputbuf>

BEGIN TRAN
UPDATE dbo.Employees SET Title=&apos;Dr.&apos; WHERE EmployeeID=1;
WAITFOR DELAY &apos;00:00:10&apos;
SELECT * FROM dbo.Orders WHERE OrderID=10258
ROLLBACK
    </inputbuf>
   </process>
  </process-list>
  <resource-list>
   <keylock hobtid="72057594043170816" dbid="7" objectname="Northwind.dbo.Employees" indexname="PK_Employees" id="lock2d69ccbbb80" mode="X" associatedObjectId="72057594043170816">
    <owner-list>
     <owner id="process2d6ae694ca8" mode="X"/>
    </owner-list>
    <waiter-list>
     <waiter id="process2d69c9748c8" mode="S" requestType="wait"/>
    </waiter-list>
   </keylock>
   <keylock hobtid="72057594044088320" dbid="7" objectname="Northwind.dbo.Orders" indexname="PK_Orders" id="lock2d69ccbbf80" mode="X" associatedObjectId="72057594044088320">
    <owner-list>
     <owner id="process2d69c9748c8" mode="X"/>
    </owner-list>
    <waiter-list>
     <waiter id="process2d6ae694ca8" mode="S" requestType="wait"/>
    </waiter-list>
   </keylock>
  </resource-list>
 </deadlock>
</deadlock-list>

虽然上面有图形化表示，但在生产环境下参考价值并不多，因为这张图蕴含的信息比较少，熟读和整理 xml 的内容就非常必要了，截图如下：

仔细观察上面的这张图可以清晰的看到，spid=66 持有了 Orders.PK_Orders 索引上哈希码为 59ce0997f9b8 键值的 X 锁，之后需要再次获取 Employees.PK_Employees 索引上哈希码为 8194443284a0 键值上的 S 锁，很不巧的是，此时的 Employees.PK_Employees 索引上哈希码为 8194443284a0 的键值已经被 spid=65 的会话附加了 X 锁，这是一种典型的相互等待造成的死锁。

同时也可以观察到，我们的语句是一个 adhoc 即时查询，其外层也没有 存储过程 之类的包围语句。

3. 寻找解决方案

知道了是什么语句和什么语句之间的冲突之后，后面的问题就比较简单了，常见措施如下：

使用 nolock 脏读

由于冲突中涉及到了 S 锁，其实绝大多数系统对脏读不是特别敏感，所以使用 nolock 无锁提示是一个好办法。

BEGIN TRAN
UPDATE  dbo.Orders SET  ShipAddress='上海' WHERE OrderID=10258
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Employees WITH(NOLOCK) WHERE EmployeeID=1;
ROLLBACK


BEGIN TRAN
UPDATE dbo.Employees SET Title='Dr.' WHERE EmployeeID=1;
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Orders WITH(NOLOCK) WHERE OrderID=10258
ROLLBACK

使用 MVCC 多版本控制

现代化的关系型数据库都支持 快照读 来解决 并发读写 的冲突，同时又能保证不脏读，简而言之就是在事务修改时将修改前的数据存到 tempdb 中来形成字段的版本化。

首先需要从 数据库 级别开启它。

ALTER DATABASE Northwind SET ALLOW_SNAPSHOT_ISOLATION ON

然后在各自事务中显式使用 SNAPSHOT 隔离级别查询，参考sql如下：

-- 会话 65 --
SET TRAN ISOLATION LEVEL SNAPSHOT
BEGIN TRAN
UPDATE dbo.Employees SET Title='Dr.' WHERE EmployeeID=1;
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Orders WHERE OrderID=10258
ROLLBACK

-- 会话 66 --
SET TRAN ISOLATION LEVEL SNAPSHOT
BEGIN TRAN
UPDATE  dbo.Orders SET  ShipAddress='上海' WHERE OrderID=10258
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Employees  WHERE EmployeeID=1;
ROLLBACK

三：总结

在真实的死锁案例集锦中，相对来说 语句顺序交错 引发的死锁会相对多一些，其次就是 书签查找，这个放到后面的文章中来聊，面对 语句顺序交错 的场景尽量的收集整理死锁的 xml数据，或许有很多意想不到的发现。

到此这篇关于SQLSERVER 语句交错引发的死锁研究的文章就介绍到这了,更多相关sqlserver语句交错引发的死锁内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:

sqlserver中的事务和锁详细解析
下面小编就为大家介绍一下事务和锁，这大概是数据库中比较难理解的东西了
2013-10-10
数据库初始化及数据库服务端操作详解
这篇文章主要为大家介绍了数据库初始化及数据库服务端操作的过程详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步早日升职加薪
2021-11-11
SQLSERVER ip地址改别名的实现示例
本文介绍了如何将SQLSERVER的IP地址改为别名,以方便网络访问和管理,通过修改HOSTS文件或DNS解析,这样不仅可以提高网络连接的稳定性和可靠性,还可以方便管理员进行远程管理和维护
2023-08-08
SQL Server误区30日谈第3天即时文件初始化特性可以在SQL Server中开启和关闭
即时文件初始化是一个在SQL Server 2005以及之上的版本鲜为人知的特性。这个特性允许数据文件(仅仅是数据文件，不包括日志文件)初始化的过程跳过填0初始化过程。这种方式是在发生灾难时大大减少Downtime的好办法---在恢复数据库时由于免去了填0初始化的过程而直接开始恢复过程
2013-01-01
SQL Server数据库备份与还原完整操作案例
在开发与运维的过程中,数据的备份与还原是经常用到的,下面这篇文章主要给大家介绍了关于SQL Server数据库备份与还原的相关资料,文中通过代码介绍的非常详细,需要的朋友可以参考下
2024-07-07
sql server 表结构修改方法
如果我们需要修改sql server表结构，应该怎么做呢?接下来将为您介绍修改sql server表结构的方法,需要的朋友可以参考下
2012-11-11
关于Mybatis的sql注释问题
这篇文章主要介绍了关于Mybatis的sql注释问题,本文通过示例代码给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下
2022-06-06
详解SQLServer和Oracle的分页查询
分页功能是我们的基本功，必须要牢固掌握。通过对分页算法的整理，希望对实现分页功能更得心应手了，需要的朋友可以参考下
2015-09-09
sql查询一个数组中是否包含某个内容find_in_set问题
这篇文章主要介绍了sql查询一个数组中是否包含某个内容find_in_set问题，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
2023-01-01
SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(中)
这篇文章主要介绍了SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(中) 的相关资料,需要的朋友可以参考下
2015-12-12