在（聚集索引）扫描过程中聚集索引是否被锁定？

Question

这个问题很简单，正如标题所说。但是，我找不到任何参考资料来证实或反驳这一点。

导致我提出这个问题的问题是我有一个视图加入了其他几个视图和表。其中一个表（我们称之为表 A）在连接条件中的列上没有覆盖非聚集索引，而是发出聚集索引扫描。

结果是所有其他也使用表 A 并使用聚集索引扫描的查询在第一个查询之后等待（还没有死锁，因为我有一个很大的超时）。一旦我在表 A 上为连接列创建了非聚集索引，聚集索引就不再使用，查询开始并行正常工作。

无论如何，如果我的假设是正确的，有没有办法检测到锁？我还没有尝试启用任何与锁定相关的跟踪标志？我现在只使用了“sp_who2”和其他一些在这里找到的查询。

如果你以前偶然发现过这个，那么请分享你的想法。

Answer 1

还有很多很多因素在起作用。

• 隔离级别。隔离级别之间的锁定行为差异很大。有些根本不锁定（读取未提交、快照、rcsi）。默认的读提交会在需要时暂时锁定它读取的行。可重复读取和可序列化保持锁定并最终锁定所有内容，许多开发人员部署可序列化但从未意识到他们这样做了。
• 扫描目的。读取扫描彼此兼容，因此无论锁定什么，它们都不会阻塞。如果您有阻止其他扫描的扫描，它们必须是用于更新的扫描，它们彼此不兼容。同样，即使在扫描更新时，快照隔离级别（包括 rcsi）也不会阻塞。
• 锁定粒度，基于基数估计。扫描可以选择行、页或行集级别的粒度。表扫描可能会选择页锁。
• 索引页锁/行锁配置，您无意中更改了这些配置。您应该恢复更改，因为它不是基于任何测量和根本原因分析。胆量的感觉没有调查作用。
• 锁升级
• 存在行外 LOB 数据时的行稳定性要求
• 其他

我建议您按照捕获单个操作的等待统计中描述的过程来捕获您观察到的扫描的等待统计为阻塞。如果它们确实阻塞了表扫描操作持有的锁，那么它们是否会阻塞。如果场景确实如您所描述的那样（读取扫描与其他读取操作），那么就没有理由阻塞，所以其他东西会起作用。您还可以尝试 sp_whoisactive 。