直接查sys.dm_exec_requests可快速定位锁等待，关键在于通过blocking_session_id揪出阻塞链：被堵会话blocking_session_id>0，堵人会话blocking_session_id=0但wait_type为lck_m_x/u且status为runnable或suspended。
怎么看 sys.dm_exec_requests 里谁在等、谁在堵
直接查 sys.dm_exec_requests 是定位锁等待最快速的入口，关键不是只看 waiting 状态，而是揪出阻塞链。被堵住的请求会显示 blocking_session_id > 0，这个值就是堵你的那个会话 ID；而堵人的会话本身 blocking_session_id 为 0，但它的 status 很可能是 runnable 或 suspended，wait_type 却是 LCK_M_X 或 LCK_M_U —— 这说明它正卡在编译或执行阶段，还没释放锁。
实操建议：
- 用以下语句一次拉出完整阻塞关系：
SELECT r.session_id, r.blocking_session_id, r.wait_type, r.wait_time, r.wait_resource, s.login_name, s.host_name, s.program_name FROM sys.dm_exec_requests r JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id WHERE r.blocking_session_id 0 OR r.session_id IN (SELECT blocking_session_id FROM sys.dm_exec_requests WHERE blocking_session_id 0)
-
wait_resource字段值像OBJECT: 5:123456 [[COMPILE]]就不是表锁，是编译锁，得往存储过程名称解析和权限方向查 - 如果
wait_resource是KEY: 5:72057594038321152:0:1:12345这种格式，说明锁在索引键上，要结合sys.dm_tran_locks查具体 object_id 和 index_id
怎么确认是不是编译锁（LCK_M_X + [[COMPILE]]）
编译锁的表现很典型：一堆会话都等同一个 OBJECT: dbid:object_id [[COMPILE]]，但阻塞者自己不报错、不长时间挂起，而是“滚动阻塞”——一个编译完，下一个立刻顶上，每个只卡几秒。这不是业务逻辑问题，是 SQL Server 编译缓存机制触发的序列化竞争。
根本原因通常是存储过程没用所有者前缀调用，比如用户 appuser 执行 EXEC mystoredproc，而该过程实际属于 dbo。SQL Server 不确定该用哪个 schema 下的同名过程，只好加独占编译锁重新解析。
实操建议：
- 查
sys.dm_exec_requests中wait_resource含[[COMPILE]]的记录，提取object_id，再查sys.objects确认是否为存储过程：SELECT name, schema_id FROM sys.objects WHERE object_id = 123456
- 修复方式只有两个：
EXEC dbo.mystoredproc（显式加 schema 前缀）或让调用用户成为过程 owner（不推荐） - 临时缓解可清空过程缓存：
DBCC FREEPROCCACHE，但别在线上高频执行，会引发集体重编译
怎么从 inputbuf 定位到真实 SQL 行号
死锁日志或 sys.dm_exec_requests 里的 inputbuf 经常只显示存储过程名，比如 EXEC usp_update_order，看不出具体哪一行 UPDATE 卡住了。这是因为 SQL Server 默认只缓存批处理首行，不是完整文本。
真正能拿到上下文的是 sys.dm_exec_sql_text，但它需要 sql_handle 或 plan_handle，而这两个字段在 sys.dm_exec_requests 里不一定有值（尤其对长期阻塞的会话，句柄可能已失效）。
实操建议：
- 优先用
sql_handle关联：SELECT t.text FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t WHERE r.session_id = 123
- 如果返回空，说明句柄无效，改查
sys.dm_exec_query_stats+sys.dm_exec_sql_text，按last_execution_time和execution_count排序找最近高频执行的语句 - 对嵌套调用，
execution_stack在死锁图 XML 里才有，需解析 XML 的frame节点，procname和line属性才对应真实行号
为什么加了索引反而锁更多、等更久
索引不是锁的解药，而是放大器。加错索引会让原本只锁几行的操作变成锁几百行，甚至触发锁升级（row → page → table）。典型表现是：同样一条 UPDATE，加索引后 sys.dm_tran_locks 显示持有更多 KEY 锁，且 wait_time 明显变长。
常见坑点：
-
WHERE条件用了函数，比如WHERE YEAR(create_time) = 2024，索引失效，全表扫描 → 大量行锁 → 锁升级 - 复合索引列顺序和查询条件不匹配，如建了
IX_user_status_created，但查询只用status = 'pending'，无法跳过前导列，扫描范围爆炸 - SELECT 列没被覆盖，导致回表（Key Lookup），额外锁聚集索引键，锁数量翻倍
验证方法很简单：对出问题的语句，开 SET STATISTICS XML ON，重点看执行计划里有没有 Index Scan、Key Lookup、Sort —— 这些都是锁扩大的信号。
