SQL Server数据库表被锁怎么办？如何查询进程并解锁？

在数据库管理中，锁机制是确保数据一致性和并发控制的基石，当锁的粒度不当或持有时间过长时，便会产生“锁表”现象，导致其他会话被阻塞，严重影响应用程序的性能和用户体验，在SQL Server环境中，有效地诊断和解决锁表问题是每位数据库管理员和开发人员必备的技能，本文将系统地介绍如何从识别、分析到解决SQL Server中的锁表问题,并提供长期的预防策略。

诊断锁表问题：找到根源

解决任何问题的第一步都是准确诊断，面对锁表，我们需要快速定位是哪个会话、哪条语句、锁定了哪个对象。

1 识别锁定的根源

SQL Server提供了多种工具和视图来帮助我们洞察当前的锁状态，最经典和直接的方法是使用系统存储过程和动态管理视图（DMV）。

• ：这是一个简单快捷的命令，可以列出当前系统中的所有会话，执行 EXEC sp_who2; 后，关注结果中的 BlkBy 列，如果某个会话的 BlkBy 列有值，这个值就是阻塞它的会话ID（SPID），通过这个线索，可以顺藤摸瓜找到问题的源头，但 sp_who2 提供的信息相对有限,无法直接看到锁定的资源类型和具体的SQL语句。

• 使用动态管理视图（DMV）：这是更强大、更现代的诊断方式，通过联合查询 sys.dm_tran_locks、sys.dm_exec_sessions、sys.dm_exec_requests 和 sys.dm_exec_sql_text，我们可以获得一幅完整的诊断图景，以下是一个常用的查询脚本，它能清晰地展示谁在阻塞谁,以及相关的SQL文本：

  SELECT 
      tl.request_session_id AS BlockedSessionID,
      wt.blocking_session_id AS BlockingSessionID,
      DB_NAME(tl.resource_database_id) AS DatabaseName,
      tl.resource_type,
      tl.resource_description,
      tl.request_mode,
      s_blocked.login_name AS BlockedLogin,
      s_blocking.login_name AS BlockingLogin,
      SUBSTRING(qt.text, (er.statement_start_offset/2)+1, 
          ((CASE er.statement_end_offset
              WHEN -1 THEN DATALENGTH(qt.text)
              ELSE er.statement_end_offset
          END - er.statement_start_offset)/2) + 1) AS BlockedQueryText,
      qt_blocking.text AS BlockingQueryText
  FROM 
      sys.dm_tran_locks AS tl
  INNER JOIN 
      sys.dm_os_waiting_tasks AS wt ON tl.lock_owner_address = wt.resource_address
  INNER JOIN 
      sys.dm_exec_sessions AS s_blocked ON tl.request_session_id = s_blocked.session_id
  INNER JOIN 
      sys.dm_exec_requests AS er ON s_blocked.session_id = er.session_id
  CROSS APPLY 
      sys.dm_exec_sql_text(er.sql_handle) AS qt
  INNER JOIN 
      sys.dm_exec_sessions AS s_blocking ON wt.blocking_session_id = s_blocking.session_id
  INNER JOIN 
      sys.dm_exec_requests AS er_blocking ON s_blocking.session_id = er_blocking.session_id
  CROSS APPLY 
      sys.dm_exec_sql_text(er_blocking.sql_handle) AS qt_blocking;

  这个查询能够详细列出被阻塞的会话、阻塞源会话、数据库名、资源类型、锁模式以及双方正在执行的SQL语句,是定位问题的利器。

2 分析锁的类型与模式

了解锁的类型有助于理解冲突的本质，SQL Server中常见的锁模式包括：

锁模式	缩写	描述
共享锁	S	用于读取操作，多个会话可以同时持有S锁。
排他锁	X	用于写入操作（INSERT, UPDATE, DELETE），会阻止其他任何锁。
更新锁	U	用于寻找待更新的行，在真正修改前会升级为X锁，可防止常见的死锁形式。
意向锁	IS, IU, IX	表明某个锁意图在资源的较低层级（如页或行）上获取，IX锁表示事务打算在表中的某些行上放置X锁。

读操作（S锁）与写操作（X锁）是互斥的，一个会话的X锁会阻塞其他所有试图获取S锁或X锁的会话,这就是最常见的锁表场景。

解决锁表问题：从应急到根治

找到问题根源后,我们可以根据情况采取不同的解决策略。

1 紧急处理：终止阻塞会话

当业务受到严重影响，需要立即恢复服务时，最直接的方法是终止（KILL）阻塞源的会话。

KILL [BlockingSessionID];

警告：这是一个高风险操作。KILL 命令会强制回滚被终止会话当前的事务，可能导致数据不一致，并且会释放该会话持有的所有锁，在执行前，务必确认该会话正在执行的操作，并评估回滚可能带来的影响，这应被视为最后的应急手段,而非常规解决方案。

2 优化SQL语句与事务

根治锁表问题的关键在于优化数据库设计和代码,减少锁的竞争和持有时间。

• 保持事务简短：事务越长，持有锁的时间就越长，造成阻塞的可能性就越大，确保事务中只包含必要的操作,尽快提交或回滚。
• 优化查询性能：低效的查询（如全表扫描）会锁定大量资源，并长时间占用锁，通过创建合适的索引，可以显著提升查询速度，让查询只锁定必要的行或页,而不是整个表。
• 避免在事务中等待用户输入：打开事务后，如果应用程序需要等待用户交互，会导致锁被长时间持有，应将业务逻辑和数据访问分离,在获取所有用户输入后再开启事务执行。
• 以一致的顺序访问对象：当多个事务需要访问多个表时，确保它们都以相同的顺序访问这些表,可以有效避免死锁。

3 调整数据库隔离级别

隔离级别决定了事务之间的可见性和锁的行为，默认的 READ COMMITTED 隔离级别下，读操作会申请共享锁（S锁），可能被写操作的排他锁（X锁）阻塞。

一个推荐的优化方案是启用 快照隔离，特别是 读提交快照（RCSI, READ_COMMITTED_SNAPSHOT）。

ALTER DATABASE YourDatabaseName SET READ_COMMITTED_SNAPSHOT ON;

启用RCSI后，READ COMMITTED 事务将使用行版本控制来提供数据的一致性读取，而不是使用共享锁，这意味着读操作不会被写操作阻塞，写操作也不会被读操作阻塞，极大地减少了读写之间的争用，是解决读-写阻塞问题的“银弹”，但需要注意，这会增加 tempdb 的存储压力和CPU开销。

预防与监控：防患于未然

最好的策略是预防，建立一套完善的监控和预警机制,可以在锁表问题造成严重影响之前就发现并处理它。

• 建立监控机制：定期执行上述的DMV查询脚本，检查是否存在长时间运行的阻塞，可以使用SQL Server Agent创建作业，当发现阻塞时间超过阈值（如5分钟）时,自动发送告警邮件。
• 使用SQL Server Profiler或Extended Events：这些工具可以捕获服务器上的详细事件，包括 Blocked Process Report，用于记录阻塞事件的详细信息,便于事后分析。
• 定期维护数据库：定期更新统计信息、重建或重组索引，确保查询优化器能生成最优的执行计划,避免因统计信息过时导致的全表扫描和意外的锁升级。

相关问答FAQs

问题1：如何快速查看当前数据库中所有的阻塞情况？

解答： 可以执行以下T-SQL脚本，它能快速列出当前所有被阻塞和正在阻塞的会话，以及它们正在执行的SQL语句,非常高效实用。

SELECT 
    r.session_id AS BlockedSessionId,
    r.blocking_session_id AS BlockingSessionId,
    s_blocked.login_name AS BlockedLogin,
    s_blocking.login_name AS BlockingLogin,
    SUBSTRING(qt.text, (r.statement_start_offset/2)+1, 
        ((CASE r.statement_end_offset
            WHEN -1 THEN DATALENGTH(qt.text)
            ELSE r.statement_end_offset
        END - r.statement_start_offset)/2) + 1) AS BlockedQueryText,
    qt_blocking.text AS BlockingQueryText
FROM 
    sys.dm_exec_requests AS r
INNER JOIN 
    sys.dm_exec_sessions AS s_blocked ON r.session_id = s_blocked.session_id
INNER JOIN 
    sys.dm_exec_sessions AS s_blocking ON r.blocking_session_id = s_blocking.session_id
CROSS APPLY 
    sys.dm_exec_sql_text(r.sql_handle) AS qt
CROSS APPLY 
    sys.dm_exec_sql_text(s_blocking.most_recent_sql_handle) AS qt_blocking
WHERE 
    r.blocking_session_id <> 0;

问题2：在查询中使用 WITH (NOLOCK) 提示是不是解决锁表的万能药？

解答： 绝对不是。WITH (NOLOCK) 提示等同于将查询的事务隔离级别设置为 READ UNCOMMITTED，它虽然能让查询不被共享锁或排他锁阻塞，从而“解决”了查询被阻塞的问题，但代价是可能会读取到未提交的“脏读”数据，导致数据不一致或重复读取、缺失读取等问题，它只适用于对数据实时性、准确性要求不高的场景，如生成粗略的报表或临时分析，在核心业务逻辑或需要精确数据的场景下，应极力避免使用 NOLOCK，而应通过优化索引、调整隔离级别（如RCSI）等更规范的方式解决问题。