SQL Server 的事务和锁（一）

来源：网络责任编辑：栏目编辑发表时间:2013-07-01 05:15　点击:次

最近在项目中进行压力测试遇到了数据库的死锁问题，简言之，如下的代码在 SERIALIZABLE 隔离级别造成了死锁：

01 SELECT @findCount=COUNT(id) FROM MyTable

02 WHERE [fk_related_id]=@Argument

04 IF (@findCount > 0)

05 BEGIN

06 ROLLBACK TRANSACTION

07 RETURN ERROR_CODE

08 END

10 INSERT INTO MyTable ([fk_related_id],…)

11 VALUES (@Argument,…)

13 COMMIT TRANSACTION

14 RETURN SUCCESS_CODE

在搞清楚这个问题的过程中做了不少的实验，与各位共享。这一篇是开篇，主要说明的是 SQL Server 的四种（其实还有别的）经典的事务隔离级别，以及在不同的隔离级别下锁的使用手段，以及所带来的不同的数据一致性。

SQL Server 中锁的种类（Schema操作就暂时不涉及了）

锁类型	描述
（Shared Lock）	用于只读操作数据锁定
（Update Lock）	用于数据的更新，在数据真正的需要更新的时候会申请升级为X锁。
X（Exclusive Lock）	独占锁，用于数据的更改。
Key-Range Lock（稍后讨论）	仅仅在 Serializable 隔离级别保护数据，以避免任何有可能使得本事务第二次读取信息产生错误的数据插入操作

SQL Server 中有四种事务隔离级别，具体的大家去参建 MSDN。下面列出在不同的事务隔离级别下这些锁是如何使用的：

隔离级别	读数据锁状态	写数据锁状态	锁持有时间
Read Uncommitted	不获得任何锁	不获得任何锁
Read Committed	数据获得S锁	对于 INSERT、DELETE、UPDATE的执行，获得X锁；对于UPDATE的标记，获得U锁；	读完即释放，并不持有至事务结束。
Repeatable Read	数据获得S锁	对于 INSERT、DELETE、UPDATE的执行，获得X锁；对于UPDATE的标记，获得U锁；	持有至事务结束
Serializable	数据获得S锁，同时获得Key-Range锁。	对于 INSERT、DELETE、UPDATE的执行，获得X锁；对于UPDATE的标记，获得U锁，同时获得Key-Range锁。	持有至事务结束