SET LOCK_TIMEOUT是唯一能在存储过程中干预锁等待的原生机制，但它只对阻塞等待生效（报错1204），对死锁（报错1205）、CPU密集型操作、I/O瓶颈完全无效；设得太小会放大超时错误，设得太大则掩盖真实性能瓶颈。
直接说结论：SET LOCK_TIMEOUT 是唯一能在存储过程中干预锁等待的原生机制，但它只对锁等待生效，对死锁、大排序、I/O 瓶颈完全无效；设得太小反而放大错误，设得太大掩盖真实瓶颈。
SET LOCK_TIMEOUT 该在哪设、设多少才有效
它不是“全局开关”，而是语句级控制，必须精准包裹在可能被阻塞的 DML 前后：
- 必须写在存储过程开头或目标语句前，例如
SET LOCK_TIMEOUT 5000（单位毫秒） - 执行完立即恢复默认：
SET LOCK_TIMEOUT -1，避免影响后续日志写入、临时表操作等隐式锁 - 设为
0表示锁冲突立即失败（报错1222），适合强实时场景；设为-1（默认）是无限等，线上慎用 - 不要在存储过程开头全局设
SET LOCK_TIMEOUT 1000—— 大量短等待直接抛Timeout expired，掩盖了到底是锁争抢还是索引缺失
为什么查不到谁在堵路？用对系统视图才看得见
sp_lock 已过时且只显示持有锁的对象，根本看不到等待链。真正要查的是阻塞源头和等待状态：
- SQL Server 2005+ 推荐组合：
sys.dm_exec_requests关联sys.dm_os_waiting_tasks - 关键过滤条件：
blocking_session_id > 0且wait_type LIKE 'LCK_%'且wait_time > 5000 - 注意：
status = 'suspended'才是真卡住；session_id = 1是系统会话，别误杀 - 如果看到
wait_type = 'CXPACKET'或'ASYNC_NETWORK_IO'，说明问题不在锁，而在并行度或客户端读取慢
长事务拆分后更慢？分片逻辑必须带索引边界
用 TOP (1000) + NOT IN (SELECT TOP ...) 分批，极易退化为全表扫描，越往后越卡。真正有效的分片必须满足：
- 使用有界条件，比如
WHERE id BETWEEN @start AND @end，而非无序IN列表 - 分片字段（如
id或created_date）上必须有索引，且是查询谓词的「最左前缀」可用索引 - 每批提交后加
WAITFOR DELAY '00:00:00.1'，缓解聚集索引尾页争抢 - 单批行数建议控制在 5000 行以内 —— 超过易触发锁升级（
LOCK_ESCALATION = TABLE），反而扩大锁范围
最容易被忽略的三个点
一是 SQL Server Agent Job 或 SSIS 调用存储过程时，CommandTimeout 完全不生效，得去作业步骤里改「超时(秒)」配置项；二是 WAITFOR DELAY 在存储过程中不会暂停任何锁持有，它只是让出 CPU；三是编译锁阻塞（waitresource LIKE '%[[COMPILE]]%'）常被当成业务锁问题，实际是因为存储过程没用所有者前缀（如 EXEC dbo.proc_name 写成 EXEC proc_name）导致反复重编译。
