set lock_timeout需置于存储过程首行，仅控制锁等待超时（毫秒级），不解决cpu或i/o瓶颈；启用read_committed_snapshot数据库级开关可避免s锁冲突；索引失效、全表扫描及事务过长是锁等待主因。
SET LOCK_TIMEOUT 要放在存储过程最开头
它只对锁等待生效，比如 KEY LOCK、PAGE LOCK 这类资源争抢，不控制 CPU 或 I/O 瓶颈。单位是毫秒，SET LOCK_TIMEOUT 3000 表示最多等 3 秒，超时直接报错 1222（不是死锁的 1205）。必须写在存储过程第一行，否则无效；如果被 IF 或 BEGIN TRY 包裹，就可能跳过执行。
READ COMMITTED SNAPSHOT 比改隔离级别更治本
单纯在存储过程里写 SET TRANSACTION ISOLATION LEVEL READ COMMITTED 没用——它仍加 S 锁，语句结束才释放，读写照样互卡。真正起效的是数据库级开关：ALTER DATABASE [YourDB] SET READ_COMMITTED_SNAPSHOT ON。启用后，读操作从 tempdb 版本链取快照，完全避开 S 锁。注意：已有连接不受影响，新连接才生效；但若存储过程里有全表扫描，版本链膨胀和 tempdb 压力会变大，得同步优化索引。
WHERE 条件没走索引，锁等待时间会指数级上升
UPDATE 或 SELECT FOR UPDATE 如果触发全表扫描，SQL Server 可能升级为页锁甚至表锁，锁住成百上千行。用 SET STATISTICS IO ON 查看执行计划，重点盯 Table Scan 和 Index Scan。常见坑包括：
-
WHERE user_id = '123'中传入字符串，而user_id是 INT，隐式转换让索引失效 - 复合索引列顺序错，比如建了
IX_orders_status_user (status, user_id)，却查WHERE user_id = 123 - WHERE 里对字段用函数，比如
WHERE YEAR(created_at) = 2024
事务边界太松，锁就“赖着不走”
锁等待时间不只是 SQL 执行慢，更多是事务拖太久。三个典型延长点：
-
OPENQUERY、xp_cmdshell或 HTTP 调用写在事务里——它们不释放锁，但可能卡住几秒 - UPDATE 后紧跟带 JOIN 的 SELECT，本可拆成两个小事务
- 一次性处理上万行，改成
TOP (200)分批 + 显式COMMIT，每批之间锁就释放了
真正难控的不是单个存储过程，而是所有开发人员是否坚持同一套锁顺序、索引规范和事务粒度——漏一个，高并发下锁等待就可能突然飙升。
