在TransactionScope (即ReadCommited )中执行的以下查询中，可能涉及什么类型的SQL锁？

Question

所以我们有四个陈述(为了问题的目的而修改)

它们在TransactionScope (ReadCommitted)中运行，多个进程可以同时调用包含这些语句的同一个存储过程：

SELECT @BathroomId = B.BathroomId
FROM Bathrooms B
WHERE B.BathroomSuite = @BathroomSuite AND B.SuiteIsAvailable = 1  
(No indexes used at all)

SELECT @OrderReceiptId = O.OrderReceiptId
FROM Order O 
WHERE O.OrderId = @OrderId 
(Clustered Index) 

IF ISNULL(@OrderReceiptId, -1) = -1
BEGIN
    INSERT INTO [dbo].[OrderReceipt]
        .....
    (Clustered index on PK) 

    UPDATE Order 
    SET OrderReceiptId = @@SCOPE_IDENTITY
    WHERE OrderId = @OrderId

从我有限的阅读中，我了解到只有行锁才能用于选择(因此，限制对这些表的争用的影响)。

但是，插入/更新将使用什么锁，这对与总体事务竞争的其他进程有什么影响？

在事务完成之前，我们是否有效地对这些表进行了分类？或者只是一些表(也就是插入和更新)--因为事务实际上只与我心目中的插入和更新相关(例如不能回滚一个选择)。

其他竞争过程是否必须等到事务完成(我认为这当然不是不合理的)？

数据库锁定和事务关系有点模糊，这是如何影响包含这些语句的存储过程的多个调用者的。

注:请忽略订单和OrderReceipt之间的不稳定关系，它肯定是次优的.

我认为我将事务合并为一种锁定机制(有点像用于线程同步的线程锁)和数据库级别的锁定。

编辑：是的，我把事务和DB锁定混为一谈(使用在一起，但职责略有不同)，任何Google101站点都会告诉我这一点。这是很尴尬的，但它会教我，因为我没有一个驼鹿第一。

Answer 1

如果有多个进程调用同一个SP，则不会出现争用或锁定、阻塞。

您的选择在您所处的隔离级别上接受一个共享锁，锁将在读取时立即释放。

但是，如果有一些更新进程或删除进程试图同时访问表，您可能会看到锁定、阻塞。

您还可以使用此traceflag to see all the locks taken ..This跟踪标志来写入为“消息”选项卡所使用的锁。

DBCC TRACEON(1200,3604,-1);
SELECT ....
DBCC TRACEOFF(1200,3604,-1);

Answer 2

如果使用的是Server，这可能取决于快照隔离级别。

据我所知，在聚集索引中插入一些内容将锁定整个表。换句话说，第一个插入将阻止所有其他插入，直到完成为止。阅读(选择)是一个不同的故事：

检查数据库的属性/选项，查找“是读取提交的快照”。如果此设置为True，则并发进程可以在您持有该插入事务时读取。否则，所有其他读取都将被阻塞，直到事务完成。

请注意，在某些情况下，打开此选项可能会影响db性能，尽管我个人对此没有任何实际问题。