SQL Server SELECT不会阻塞同类型查询详解：特殊情况下的误解

在SQL Server中，关于SELECT语句是否会阻塞其他SELECT查询，通常情况下是不会的。一个标准的SELECT查询执行时只申请意向共享锁(IS)和共享锁(S)，这两种锁模式之间是兼容的，这意味着一个SELECT操作不会阻止另一个SELECT在同一对象上进行。这基于SQL Server的并发控制机制，确保读操作之间的互不干扰。 然而，在特定场景下，如果存在并发操作，如UPDATE或DELETE，事情可能会有所不同。例如，当一个事务（如会话窗口A中的UPDATE语句）持有排它锁(X)或意向排他锁(IX)时，这会导致其他试图对该行获取共享锁的操作（如会话窗口B和C的SELECT语句）被阻塞，因为排它锁对所有类型的锁（包括共享锁）都是排斥的。在这种情况下，会话B和C会被挂起，等待会话A释放锁资源，其等待事件显示为LCK_M_S，表示锁定冲突。 测试数据的创建和实验步骤进一步证实了这一点。通过创建一个表和索引，并在两个会话中分别执行UPDATE和SELECT查询，当UPDATE操作持有排它锁时，第三个SELECT查询就会被阻塞，直到UPDATE操作完成或者被显式回滚。 总结来说，SQL Server中的SELECT并不会在常规情况下阻塞SELECT，除非涉及到了并发控制下的排它锁冲突。理解这些锁机制对于优化数据库性能和避免死锁至关重要，特别是在高并发环境下。开发者和DBA需要密切关注这些锁行为，以便更好地管理并发访问和维护系统的响应性。