• 欢迎光临~

SQL Server死锁报错分析

开发技术 开发技术 2021-01-01 366次浏览
概述
最近遇到一个生产环境的问题,报错如下:
事务(进程 ID 89)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。
拉取了请求日志,该接口有并发的请求,在同一时刻,有多个请求。分析了下代码,主要的部分是包裹在事务中,且给主要的数据更新加了数据库资源锁。可见
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-getapplock-transact-sql?view=sql-server-ver15
但最后还是报了上面的错误。
分析
首先,这个报错,是数据库级别的报错。代码层面,看了几遍代码,考虑了各个场景并没有问题。也就是说,是在数据库中更新表的时候,SQL SERVER报错了。报错时有抓到报错的语句,分析了下,是更新某张表的字段时,报错的。一开始一直在分析代码层面,但是始终没思路。后台和同事分析了下报错的SQL语句。有这么一个问题,如果,在一个事务内,对表加了锁,但是这个更新比较慢,查看执行计划走的时候索引扫描;而这个时候有并发的情况,所有的请求都要执行这段更新的语句,那么就有问题了。如下
SQL Server死锁报错分析
请求1更新时有一定的更新时间,并发请求2,3,4,5来了,那么都会排队,而且需要select 查询更新的table以及其他的资源,而请求1也会查询其它请求锁 锁住资源。一旦更新时间长,且SQL阻塞了,就会有死锁的问题。
解决
既然是SQL更新问题,那么第一查看的应该是索引。看了下索引,的确有关于这段更新SQL的索引,但是更新的字段顺序不对,导致走的时候索引扫描,而不是索引查找。满足索引查找的一般性结论:如果条件中包含WHERE或者ON的话,查询条件必须是位于索引集合.........
{{o.name}}
{{m.name}}
程序员灯塔
转载请注明原文链接:SQL Server死锁报错分析
喜欢 (0)
违法和不良信息举报电话:022-22558618 举报邮箱:dljd@tidljd.com