sql server存储过程编译锁导致高并发阻塞，根本原因是未用完全限定名调用（如exec mystoredproc而非dbo.mystoredproc），引发缓存查找失败、强制申请独占编译锁lck_m_x，造成滚动阻塞；识别关键为wait_type=lck_m_x且waitresource含[[compile]]，解决核心是统一使用schema.名称调用确保计划复用。
SQL Server 存储过程编译锁会直接卡住高并发请求，不是因为慢，而是因为序列化编译必须抢同一把独占锁（LCK_M_X），只要一个会话在编译，其他所有同名过程调用都得排队等——这不是性能问题，是设计机制导致的串行瓶颈。
为什么 exec mystoredproc 会触发编译锁
SQL Server 对存储过程执行计划的缓存查找依赖**完全限定名**。如果调用时没写 dbo.mystoredproc 而只写 mystoredproc，引擎无法确认该名称是否唯一（比如是否存在 hr.mystoredproc），于是放弃复用已有计划，转而申请独占编译锁、重新编译。
- 用户不是对象所有者时，未限定调用必走编译路径
- 即使过程已存在且执行过，只要名字解析不明确，就跳过缓存直奔编译
- 这个锁的
waitresource长这样：OBJECT: 6:834102 [[COMPILE]]，其中834102是过程的对象 ID，不是表 - 编译完成瞬间，下一个等待者立刻上位成为新的阻塞源头，形成“滚动阻塞”，单个 SPID 不会长期占着不放
如何从 sys.dm_exec_requests 快速识别编译阻塞
查 sys.dm_exec_requests 时重点盯 wait_type 和 waitresource，而不是只看 blocking_session_id：
-
wait_type = 'LCK_M_X'且waitresource含[[COMPILE]]字样 → 基本锁定是编译锁问题 - 阻塞方（
blocking_session_id = 0）的status往往是runnable，不是suspended - 被阻塞方的
wait_time通常不大（几百毫秒级），但队列可能很长 —— 因为每个新请求都在末尾排队 - 用
sys.dm_exec_sql_text查sql_handle，确认被堵住的确实是EXEC语句，而非普通 UPDATE
怎么避免编译锁成为瓶颈
核心思路是让 SQL Server 每次都能**无歧义地命中缓存计划**，绕过编译阶段：
- 所有调用必须使用完全限定名：
EXEC dbo.usp_calculate_price，禁止裸名EXEC usp_calculate_price - 确保调用用户对过程有
EXECUTE权限，且不依赖跨 schema 解析逻辑 - 上线前统一检查应用代码、ORM 配置、SSIS 包里的调用写法，一个漏网就可能引发雪崩
- 不要依赖
WITH RECOMPILE或sp_recompile做“热更新”——它们会主动清空计划并强制后续调用重编译
真正麻烦的不是锁本身，而是它藏得深：现象像慢查询，日志里没有明显报错，blocking_session_id 可能为 0，sys.dm_tran_locks 里也找不到对应记录——因为编译锁不走常规事务锁管理器，只在编译路径上生效。一旦忽略 [[COMPILE]] 这个关键词，排查就会转向错误的方向。
