当前位置：首页 > 问答 > 正文

SQL Server里那些让人头疼的阻塞情况到底都有哪些表现和原因呢

畅苗
问答
2026-01-03 23:49:16
23

根据微软官方文档、SQL Server资深工程师的实践经验总结以及像Brent Ozar、Paul Randal等知名专家的公开分享，SQL Server中的阻塞问题表现多样，其背后的原因也错综复杂，下面详细列出这些让人头疼的情况。

阻塞的常见表现

当数据库发生阻塞时,最直接的感觉就是“慢”，但这种“慢”有不同的表现形式，很容易被误认为是硬件或一般性能问题。

应用程序响应极其缓慢或超时：这是最直观的表现，用户在前端点击一个按钮，原本一秒内完成的查询，现在一直转圈，最后可能弹出一个超时错误，整个应用的体验变得非常卡顿。
特定查询长时间运行且无法结束：在SQL Server Management Studio（SSMS）中执行一个简单的查询，但查询一直处于“执行中”状态，看不到结果，也无法取消（或取消操作本身也被阻塞），这通常是因为这个查询需要获取的某个资源正被另一个会话独占着。
系统监视器（PerfMon）中出现资源等待：通过性能计数器观察，会发现“Average Wait Time (ms)”和“Lock Waits/sec”这两个指标持续处于高位，这表明有很多任务正在花时间等待锁的释放，而不是在执行实际的工作。
活动监视器（Activity Monitor）中看到“阻塞链”：在SSMS的活动监视器里，可能会清晰地看到一条“阻塞链”，通常会有一个“头部阻塞者”（Head Blocker），它的状态是“RUNNING”，而下面挂着一长串状态为“SUSPENDED”的会话，这些被阻塞的会话的“等待类型”通常是“LCKM*”（如LCK_M_S表示等待共享锁）。
突然的并发能力下降：在系统用户量或业务并发量并不算很高的情况下，系统却表现出无法处理多个并发请求，串行执行的感觉很强，这往往是因为某个频繁执行的操作持有锁的时间过长，导致了并发瓶颈。

阻塞的主要原因

阻塞的本质是并发事务对资源（主要是数据页、行、表）的锁竞争，让人头疼的阻塞通常源于不良的数据库设计、低效的代码或不当的配置。

长时间运行的事务：这是最经典的原因，根据微软的锁定机制，在一个事务内部获取的锁，通常要等到事务提交（COMMIT）或回滚（ROLLBACK）时才会释放，如果一个事务开启了却长时间不结束（比如在事务中进行了复杂的操作，然后等待用户输入，或者应用程序逻辑错误导致事务未正常关闭），那么它持有的所有锁都会一直阻塞其他需要相同资源的事务，Brent Ozar在他的培训中经常强调“保持事务尽可能短小精悍”是减少阻塞的第一原则。
不合适的查询语句导致锁升级：SQL Server为了节省管理锁的开销，会在单个语句持有过多细粒度锁（如行锁）时，自动将其升级为更粗粒度的锁（如页锁或表锁），如果一个查询扫描了大量数据并试图更新，可能会触发锁升级，直接锁住整个表或整个页，这会瞬间阻塞所有其他需要访问该表的事务，并发性急剧下降。
缺失或不合理的索引：索引的作用之一是快速定位数据，减少需要扫描和锁定的数据范围，如果一个常用的查询条件字段没有索引，SQL Server就只能进行全表扫描，在全表扫描过程中，为了确保数据一致性，它可能会对扫描过的所有行（甚至整个表）施加锁，大大增加了与其他事务发生锁冲突的概率，Paul Randal在其博客中多次指出，很多阻塞问题的根源在于糟糕的索引设计。
不合理的事务隔离级别：默认的“已提交读”（READ COMMITTED）隔离级别在大多数情况下是平衡的，但如果为了更高的数据一致性而使用了更严格的隔离级别，如“可重复读”（REPEATABLE READ）或“可序列化”（SERIALIZABLE），事务会持有它读取过的数据的共享锁直到事务结束，这极易导致读操作阻塞写操作，反之，如果使用了“未提交读”（READ UNCOMMITTED）虽然能避免阻塞，但可能读到“脏数据”。
应用程序设计缺陷：交互式事务：这是一种非常隐蔽但危害极大的情况，应用程序开启一个事务，执行一些数据库操作，然后在事务尚未提交的情况下，弹出一个对话框等待用户进行选择或输入，在用户慢悠悠地思考并点击“确定”的这几分钟甚至几十分钟里，数据库事务一直保持打开状态，其持有的锁也一直不释放，从而阻塞了所有其他用户，这种模式在客户端/服务器架构的应用中曾经非常常见。
对象架构修改锁（Sch-M锁）的阻塞：当执行像创建索引、更新统计信息（在某些情况下）、或者使用sp_rename等DDL操作时，需要对对象施加架构修改锁，这个锁是排他性的，会阻塞所有其他访问该对象的连接，如果对一个繁忙的大表在线创建索引操作不当，可能会引发严重的阻塞。
热点资源竞争：当多个并发事务试图同时修改同一数据页上的最后一条记录，或者争用像标识列（IDENTITY）这样的序列发生器时，即使每个事务都很快，也会因为串行访问而形成瓶颈，产生PAGELATCH等待（注意不是LOCK），其表现很像阻塞。

SQL Server的阻塞问题就像交通堵塞，既有可能是由于个别“车辆”（长事务）抛锚占道，也有可能是“道路设计”（数据库/应用设计）不合理，或者“交通规则”（隔离级别、锁机制）使用不当造成的，解决它需要综合运用监控工具（如活动监视器、动态管理视图DMVs）定位问题源头，并从事务管理、索引优化、代码重构和应用程序设计等多个层面进行系统性优化。