SQL高并发下锁等待怎么查_阻塞会话分析方法【指导】

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 递归查询或分步操作：

标签： session ai 有锁