Bud*_*hiP 5 sql-server isolation-level
假设一个SQLCmd会话正在使用事务隔离级别REPEATABLE READ。
在这个会话中，我开始一个事务并在非索引列上执行一个UPDATE带有WHERE子句的语句。该语句应该WHERE为表中的每条记录评估子句，但只有一条会匹配。
如果我在运行UPDATE语句后检查放置在此事务下的锁，我只能看到IXTable 和 Page 上的两个锁，以及X更新的行上的锁。
我的问题是：数据库引擎不应该在它读取的所有行上放置共享锁以确保REPEATABLE READ吗？如果某个其他事务更新了一条记录，使其与 UPDATE 语句中的 WHERE 子句匹配，从而违反了REPEATABLE READ.
如果我执行 a SELECT *，那么我可以看到它S在每一行上放置了锁，这些锁尚未用X.
任何人都可以帮助我了解这种情况吗？
我已经尝试过 SQL Server 2008 R2 和 2012，两者的行为相同。
好吧，有两件事：
语句始终UPDATE会在其更新的行上放置排它锁。对于任何隔离级别都是如此- 并且由于这些行已经被独占锁定 - 还需要添加共享锁吗？XS
在隔离级别下，事务中的REPEATABLE READ任何行都将具有共享锁，并且该锁将一直保持到事务结束 - 这也意味着：您在事务中选择的任何行将无法被另一个事务独占锁定（对于更新或删除操作）SELECTS
所以我想说：你所看到的绝对是正确的和预期的行为。
查看更多相关资源：
| 归档时间： |
|
| 查看次数： |
841 次 |
| 最近记录： |