SQL Server锁等待需通过sys.dm_exec_requests定位阻塞会话，用sys.dm_tran_locks查持有锁者，结合CTE追溯阻塞链根因，并通过查询存储、事件通知等常态化监控预防。
查锁等待：从系统视图快速定位阻塞源头
SQL Server 中锁等待的本质是会话 A 持有资源（如某行、页或表），而会话 B 请求冲突锁（如 X 锁 vs S 锁）时被挂起。最直接的入口是 sys.dm_exec_requests，它能立刻告诉你哪些会话正在等、等什么、等了多久：
- blocking_session_id > 0 表示该会话正被阻塞；值为 0 则是正常运行或自身为阻塞源
-
wait_type 显示等待类型，常见如
LCK_M_U（等待更新锁）、LCK_M_X（等待排他锁）、WRITELOG（日志写入慢，间接引发锁堆积） - wait_time / 1000.0 AS wait_time_seconds 把毫秒转成秒，超过 5 秒就值得立即关注
-
resource_description 在部分等待中会显示具体被锁对象（如
KEY: 5:72057594044837888 (b500a9c7e8f9)），可结合sys.dm_db_page_info追踪到表和索引
看谁在持锁：用 sys.dm_tran_locks 分析锁粒度与对象
仅知道“谁被卡住”不够，必须确认“谁卡住了别人”。sys.dm_tran_locks 是核心视图，它记录所有当前活跃锁。重点筛选 request_status = 'GRANT' 的持有锁记录，并关联对象名：
- 先查基础锁分布：
SELECT request_session_id, resource_type, resource_database_id, DB_NAME(resource_database_id), request_mode, request_status FROM sys.dm_tran_locks WHERE request_status = 'GRANT' - 若
resource_type IN ('OBJECT', 'PAGE', 'KEY', 'RID')，可用OBJECT_NAME(resource_associated_entity_id, resource_database_id)直接获取表名（注意：对 KEY/RID 需配合sys.partitions解析分区 ID） - 特别关注
request_mode = 'X'（排他锁）或'U'（更新锁）且持续时间长的会话——它们大概率是阻塞源
追溯阻塞链：找出根因会话与执行语句
一个会话可能被层层阻塞（A→B→C），需定位最上层的“根阻塞会话”。推荐用 CTE 递归查询或分步操作：
- 第一步：找出所有阻塞者（
blocking_session_id > 0）并去重，得到潜在根会话列表 - 第二步：对每个根会话，查
sys.dm_exec_sessions和sys.dm_exec_requests获取其login_name、host_name、program_name，判断是否来自应用、SSIS 或 SQL Agent - 第三步：用
sys.dm_exec_sql_text(sql_handle)提取该会话最后执行的 SQL 文本。若文本是空或不可读，说明事务已开始但尚未执行语句（比如 BEGIN TRAN 后挂起） - 关键提示：不要只看
last_request_end_time，要结合open_transaction_count > 0判断是否长事务未提交
日常监控与预防建议
靠临时查视图救火效率低，建议建立轻量级常态化手段：
- 启用 查询存储（Query Store），开启自动捕获阻塞相关等待事件（如 LCK_*），便于回溯历史执行计划变化
- 部署基于 事件通知（Event Notification） 的阻塞捕获框架，实时写入日志表，避免错过短时阻塞
- 应用层强制设置 command timeout（如 30 秒），防止一个慢事务拖垮整个连接池
- 避免在事务中混入非数据库操作（如 HTTP 调用、文件读写），缩短事务生命周期
- 对高频更新表，检查是否缺失索引导致升级为页锁或表锁；UPDATE/DELETE 务必带上高选择性 WHERE 条件
