EXISTS 查询仍会锁定表吗？

Question

IF NOT EXISTS(SELECT * FROM MyTable WITH(nolock) WHERE Key = 'MyKey')
  INSERT MyTable(Key) Values('MyKey')

如果表中不存在该值，查询是否需要锁？

Answer 1

来自文档：

READUNCOMMITTED 和 NOLOCK 提示仅适用于数据锁。所有查询（包括具有 READUNCOMMITTED 和 NOLOCK 提示的查询）都会在编译和执行期间获取 Sch-S（架构稳定性）锁。因此，当并发​​事务持有表上的 Sch-M（架构修改）锁时，查询将被阻塞。例如，数据定义语言（DDL）操作在修改表的模式信息之前获取Sch-M锁。当尝试获取 Sch-S 锁时，任何并发查询（包括使用 READUNCOMMITTED 或 NOLOCK 提示运行的查询）都会被阻止。相反，持有 Sch-S 锁的查询会阻止尝试获取 Sch-M 锁的并发事务。有关锁定行为的详细信息，请参阅锁定兼容性（数据库引擎）。

因此它不会获取数据锁，但仍会获取架构稳定性锁。

Answer 2

EXISTS 通常仍会获取锁。但你添加了一个提示，告诉它不要这样做，所以它不会。

Answer 3

使用 NOLOCK 提示确实可以防止行锁。但请注意，这种“查找和插入”充满了问题。该操作不是原子操作，当两个会话都发现密钥丢失并都尝试插入时，尝试执行此操作的两个会话将导致竞争条件，从而导致其中一个会话导致重复密钥冲突。它是否也是次优的，因为索引查找发生两次（一次查找键，一次定位插入位置）。最佳且正确的解决方案是实际尝试插入重复键错误并从该错误中恢复（如果已存在）。

Answer 4

该代码很容易出错。相反，您可以尝试：

在表上放置一个唯一索引，以便不可能插入多个冲突的行，然后直接插入。冲突会产生错误，您需要处理该错误。

或者，如果冲突是预期条件而不是异常，那么您需要使插入/检查原子化：

insert MyTable( [Key] ) 
  select 'MyKey' 
  where not exists ( 
    select * 
    from MyTable 
    where [Key] = 'MyKey' 
)

另外，请注意，(nolock) 和 Read Uncommissed 根据设计不会产生准确的结果。对于报告等来说是可以的，但是根据使用（nolock）的决策对数据采取行动是危险的。