数据库的读读事务也会产生死锁

前段时间有朋友问：SQL Server的AlwaysOn的辅助数据库默认会使用行版本快照控制来消除数据库上的读写事务阻塞和死锁问题

即使用户显式为查询设置了其他事务隔离级别，所有锁提示（Lock Hint）都会被忽略。

为了保证数据同步的完整性，AlwaysOn规定来自数据同步（redo 日志）所做的写操作永远不会被选为死锁牺牲品，无论该写操作的代价多小。

AlwaysOn的做法其实很好理解，数据库中的事务操作无非就四种

1、读读

2、读写

3、写读

4、写写

第二种、第三种和第四种造成阻塞和死锁很容易理解，读事务得到的锁资源不释放就有可能造成写事务失败或者写事务得到的锁资源不释放就有可能造成读事务

但是第一种读读事务也会造成死锁吗？

我这里做一个实验

1、先确保数据库没有使用任何快照隔离级别

USE [tt1]DBCC USEROPTIONS

2、脚本1

USE [tt1];SET TRANSACTION ISOLATION LEVEL SERIALIZABLEBEGIN TRANSELECT * FROM [dbo].[Table_1] WITH (ROWLOCK)  WHERE [q]=88

3、脚本2

USE [tt1];SET TRANSACTION ISOLATION LEVEL SERIALIZABLEBEGIN TRANSELECT * FROM [dbo].[Storage] WITH (TABLOCKX)SELECT * FROM [dbo].[Table_1] WHERE [q]=7

4、脚本3

USE [tt1];SET TRANSACTION ISOLATION LEVEL SERIALIZABLEBEGIN TRANSELECT * FROM [dbo].[Table_1] WITH (ROWLOCK) WHERE [q]=88

5、脚本4

USE [tt1];SET TRANSACTION ISOLATION LEVEL SERIALIZABLEBEGIN TRANSELECT * FROM [dbo].[Table_1] WITH (ROWLOCK) 

6、在多个查询窗口（session）里执行上面的脚本

7、打开跟踪标记

 DBCC TRACEON (1204, 1222, -1); DBCC tracestatus

8、过一会儿就会看到其中一个session 59已经作为死锁牺牲品

9、在errorlog里已经看到spid为4的死锁监视器（LOCK MONITOR）已经监测到死锁的存在

EXEC xp_readerrorlog 0,1,NULL,NULL,'2015-08-06','2015-10-10','DESC'

总结

多人都不了解为什么SELECT语句也会产生死锁，其实SELECT语句一般在RC隔离级别下很少会发送死锁，只是用户在日常开发中会使用了一些不恰当的锁提示（Lock Hint）或者提升了事务隔离级别而导致

日常开发中我们都要注意不要滥用锁提示（Lock Hint），根据实际情况进行判断，该提升事务隔离级别就提升事务隔离级别，以免造成不必要的死锁。

如有不对的地方，欢迎大家拍砖o(∩_∩)o