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

SQL server里那些让人头疼的阻塞情况到底是啥意思，怎么理解和应对

畅苗
问答
2026-01-04 07:46:37
22

说到SQL Server里的阻塞，你可以把它想象成一个非常窄的独木桥，或者一个只有一个收银台的超市，这个“独木桥”或“收银台”就是数据库里的一份数据，比如一条用户信息记录,或者一个系统设置值。

阻塞到底是啥意思？

简单说就是：一个任务（我们叫它会话A）正站在独木桥上干活（比如修改这条数据），它为了防止别人干扰，就暂时把这桥“霸占”了，上了个锁，这时候，另一个任务（会话B）也想来这个桥上干点别的事（比如读取或修改同一条数据），但它发现桥被占了，门上挂了锁，会话B没办法，只好在桥头等着，这种“后面的人等着前面的人完事”的现象,就是阻塞。

阻塞其实是数据库确保数据“不出错”的看家本领，是正常现象，想象一下，如果两个人同时修改同一条银行账户余额，没有锁的话，最后结果肯定是一团糟，适度的阻塞和等待,是保证数据准确性的必要代价。

那什么情况下阻塞会“让人头疼”呢？

当这种等待变得不正常的时候。

桥上的人干活太慢（长时间运行的事务）： 这是最常见的原因，会话A开始修改数据，但它的活计非常复杂，或者因为它自己在等应用程序的下一步指令，导致它长时间占着桥不撒手，后面排队的会话B、C、D全都只能干等着，应用程序那头的用户就会感觉页面“卡死”了，转圈圈，无法操作，根据微软官方文档和SQL Server技术社区的普遍认知，一个查询如果等待超过30秒,通常就值得警惕了。
桥上的人忘了下桥（事务未提交或回滚）： 更糟糕的情况是，会话A干完活后，没有主动说“我干完了”（即没有提交或回滚事务），它可能因为程序bug、网络中断或用户直接关闭了客户端而“失踪”了，但它占着的锁却一直不释放，这就好比有人进了厕所隔间，然后从窗户溜走了，门还从里面锁着，外面的人永远也进不去，这个锁会一直堵着，直到数据库管理员（DBA）发现并“强制清场”。
桥设计得太窄（锁的粒度或模式不合适）： 会话A只是想读一下整张表里有多少条数据，但它却非常霸道地申请了一个会阻塞所有其他人的锁（比如在某些隔离级别下），这就好比一个人只是想看看桥的风景，却把整座桥都给封了，不让任何人过，这可能是因为查询语句写得不好,或者事务隔离级别设置得过高导致的。

怎么理解和应对这些头疼的阻塞？

核心思路是：快速定位“谁”在堵着“谁”，然后解决那个“堵源”。

学会看“路况”（监控和诊断）：
- 活动监视器： 这是SQL Server自带的图形化工具，就像交通监控中心的大屏幕，你可以在里面直接看到“正在等待的任务”是哪些，以及“阻塞链”（谁堵了谁，谁又被谁堵了）一目了然，对于初学者来说,这是最直观的方法。
- 动态管理视图： 这是给更专业的人士用的“高级诊断仪”，比如查询 sys.dm_exec_requests 视图，可以找到状态是“ suspended”或“runnable”的会话，再看它的 blocking_session_id 字段，就知道它被谁阻塞了，通过 sys.dm_tran_locks 视图，能看到当前数据库里所有的锁信息,这些信息能帮你精确判断阻塞的根源。
针对性地“疏导交通”（应对策略）：
- 对付“干活慢”的： 这是根本原因，需要优化那个运行缓慢的查询。
  - 检查有没有缺失索引？给经常查询的字段加个索引，就像给桥拓宽车道,能极大提高通过速度。
  - 查询语句写得是否高效？避免使用 SELECT *，只取需要的字段；检查是否有复杂的嵌套查询可以简化。
  - 应用程序的逻辑是否合理？是否在事务中执行了不必要的耗时操作（比如在数据库事务里调用外部API）？应该让事务尽量短小精悍。
- 对付“不下桥”的： 这是紧急情况，需要“强制清场”。
  - 在活动监视器或通过 KILL 命令，结束那个“失踪”的会话的事务，但这相当于强行把占着厕所的人拽出来，如果它的工作没完成，可能会留下一堆烂摊子（数据不一致），所以这是个不得已而为之的操作，更重要的是从源头解决,确保应用程序能正确地提交或回滚每一个事务。
- 对付“桥太窄”的：
  - 审查并优化事务隔离级别，在满足业务要求的前提下，使用允许更高并发性的隔离级别（如读已提交快照），SQL Server的“读已提交快照”功能就是一个很好的解决方案，它允许读者不阻塞写者，写者也不阻塞读者，就像给读操作修了一条观光栈道,不用都挤在通行的主桥上。
  - 优化查询和索引，减少全表扫描的需要，让查询能更精准地锁定少量数据,从而使用更细粒度的锁。