UPDATE 锁并不是一种单独的锁类型，倒是有点像是SHARED和EXCLUSIVE锁的混合。并且可能与你认为的不同，UPDATE 锁不是由UPDATE操作获取的。 当SQL Server执行一个数据......
UPDATE 锁并不是一种单独的锁类型，倒是有点像是SHARED和EXCLUSIVE锁的混合。并且可能与你认为的不同，UPDATE 锁不是由UPDATE操作获取的。 当SQL Server执行一个数据修改操作，但是需要首先执行一个检索来查找需要修改的资源时，事务会获取这种类型的锁。
当SQL Server搜索时，它不需要获取EXCLUSIVE锁，只有在找到要更改数据时，才需要EXCLUSIVE锁。通常情况下，如果SQL Server进程只是搜索数据，它会在所访问到的每个资源上获取SHARED锁，然后确定是否已经找到了正在搜索的数据。但是，如果要搜索的数据是用来修改的话，SQL Server启用SHARED锁则存在潜在问题。例如，两个进程都是寻找相同的资源（如Customers表中同一客户行）进行修改，使用不同的访问的路径，并且它们在同一时间达到所需的资源。如果它们都在检索的数据上获取SHARED锁，它们都可以同时锁定要修改的资源，但在它们进行修改前需要将锁转换为EXCLUSIVE锁。 由于另一个进程具有了SHARED锁，则不会生成EXCLUSIVE锁。 每个进程都具有一个SHARED锁，并且每个都尝试将其转换为EXCLUSIVE的锁，但是都会由于另外一个进程的存在，这两个尝试都不会成功。这是一种死锁情况，叫做“转换死锁”。
UPDATE 锁是一种死锁避免机制。如果SQL Server使用UPDATE锁，则死锁将不会发生。 如果SQL Server进程开始了一个最终要修改数据的搜索操作，它获取
1/4 1 2 3 4 下一页 尾页 |
