可序列化隔离级别的意外行为

Question

测试设置

我有一个 SQL Server 2014 和一个简单的表 MyTable，其中包含列 Code (int) 和 Data (nvarchar(50))，没有为此表创建索引。

我在表中有4条记录，方式如下：

1, First
2, Second
3, Third
4, Fourth

然后我在事务中运行以下查询：

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

BEGIN TRANSACTION

DELETE FROM dbo.MyTable 
WHERE dbo.MyTable.Code = 2

我有一个受影响的行，我没有发出 Commit 或 Rollback。

接下来我开始另一个事务：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

BEGIN TRANSACTION

SELECT TOP 10 Code, Data
  FROM dbo.MyTable
  WHERE Code = 3

在这一步，带有 SELECT 查询的事务挂起，等待带有 DELETE 查询的事务完成。

我的问题

我不明白为什么带有 SELECT 查询的事务正在等待带有 DELETE 查询的事务。据我了解，删除的行（代码 2）与所选行（代码 3）无关，据我了解，隔离级别 SERIALIZABLE SQL Server 在这种情况下不应该锁定整个表。也许发生这种情况是因为 SERIALIZABLE 的最小锁定量是一个页面？然后，如果表有更多行，例如 1000000（其他页面中的某些行不会被锁定），那么它可能会产生从其他页面中选择行的不一致行为。请帮助弄清楚为什么在我的情况下会发生锁定。

Answer 1

在锁定 READ COMMITTED、REPEATABLE READ 或 SERIALIZABLE 下，SELECT 查询必须为查询计划实际读取的每一行放置共享 (S) 锁。锁可以放置在行级、页级或表级。此外，SERIALIZABLE 将在范围上放置锁，这样在持有锁时没有其他会话可以插入匹配的行。

因为您“没有为此表创建索引”，所以这个查询：

SELECT TOP 10 Code, Data
  FROM dbo.MyTable
  WHERE Code = 3

必须通过表扫描执行，并且必须读取所有行（即使是 Code=2 的行）以确定它们是否符合 SELECT 条件。

这就是为什么您应该几乎总是使用Row-Versioning 的原因之一，要么将数据库设置为 READ COMMITTED SNAPSHOT，要么将只读事务编码为使用 SNAPSHOT 隔离。