SQL Server死锁的解决过程

共计 1787 个字符，预计需要花费 5 分钟才能阅读完成。

某现场报一个 SQL 死锁，于是开启了 1222 跟踪：

一段时间之后拷贝 ERROR 文件查找相关信息，比较有用的摘录出来如下：

语句一：

语句二：

相关的死锁资源如下：

可以明显的看到是 select 语句与 insert 语句产生了死锁，争用的资源分别 6996 和 11086 这两个 page，这里比较奇怪因为 sqlserver 在默认隔离级别下，select 操作会迅速释放页上的 S 锁，因此不存在形成死锁的基础 – 不可剥夺条件。

但其实这里是一种形成死锁的典型条件，参考宋大神的一幅图这里：– 由书签查找产生的死锁。

其原理为：

1. 由最初的 update 语句产生数据页 A 的 IX 锁，更新完毕后要请求索引页 B 的 IX 锁以便更新索引，但此时 B 页上已有与 IX 不兼容的 S 锁。

2. 而 select 语句在索引页 B 上加了 S 锁后，正要通过书签查找获取数据页 A 的数据，要获取 A 页就要在 A 页上暂时加 S 锁，但 A 页又被 update 语句加了不兼容的 IX 锁，因此两个进程形成环路等待 —- 死锁。

根据死锁的产生原理决定进行以下优化：

1. 优化 select 语句使其尽快完成以减少死锁频率。

2. 对 select 语句使用 nolock 选项以避免死锁问题。

3. 通知开发优化相关代码的执行顺序来避免死锁问题。

最终优化了 select 语句，其他两条交给开发做修改。

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-06/144604.htm