Transaction And Lock--唯一索引下INSERT导致的死锁

背景：

曾经的一位同事问我:"数据库只有并发INSERT 操作，会造成死锁么？"，我没有太多思考地回答"不会"，但真的不会吗？

测试：

--=================================
--创建测试表
CREATE TABLE TB3
(
    ID INT PRIMARY KEY
)
GO
--===================================
--新开回话1
BEGIN TRAN
INSERT INTO TB3
SELECT 2
WAITFOR DELAY '0:0:10'
INSERT INTO TB3
SELECT 1
--===================================
--新开回话2
BEGIN TRAN
INSERT INTO TB3
SELECT 1

WAITFOR DELAY '0:0:10'
INSERT INTO TB3
SELECT 2

在上面的两个回话中，由于主键(唯一约束)的限制，相同的key对应相同的lock Resource，导致需要等待对方所获取的lock Resource，从而引发死锁

而如果将主键修改为非唯一索引，则不会引发死锁，相同的key对应不相同的lock Resource,因此不会造成相互等待也不引发死锁。

--====================================================================

--华丽的PS

对于最常见的死锁场景：

事务1 获取表TB1上的资源，请求表TB2上的资源

事务2 获取表TB2上的资源，请求表TB1上的资源

很多开发人员都会有意识保证各个事务访问不同表的顺序，从而避免此类死锁的发生，但很少会考虑对相同表的访问顺序，尤其在输入值被参数化的情况，如在下面的情况下:

BEGIN TRAN
UPDATE TB1
SET C2=@P2
WHERE C1=@P1

UPDATE TB1
SET C2=@P3
WHERE C1=@P3

COMMIT

在考虑是否会引发死锁时，我们除了分析当前语句外，还得检查这些语句所涉及到的表相关对象：触发器+外键+索引，还需分析其他业务场景的潜在影响。

PS:很多我们自认为正确的小结论，洗洗(细细)分析下，根本就是错误，而这些西奥结论，可能造成很恶劣影响。

--========================================================

照例妹子镇贴

图片来源于一豆瓣友邻