sp_lock看不到等待是因为它只显示持有锁的对象，不反映阻塞源头；应使用sys.dm_exec_requests与sys.dm_os_waiting_tasks关联查询blocking_session_id和LCK_%等待。
为什么 sp_lock 看不到等待，但实际执行卡住？
因为 SQL Server 默认不记录锁等待链的完整上下文，sp_lock 只显示当前持有锁的对象，不反映阻塞源头。真正要查的是谁在等、等谁、等了多久。
实操建议：
- 改用
sys.dm_exec_requests+sys.dm_os_waiting_tasks关联查：重点看blocking_session_id > 0和wait_type LIKE 'LCK_%' - 加时间过滤：只查
wait_time > 5000（5秒以上）的请求，避免噪音 - 注意
session_id = 1是系统会话，别误杀；status = 'suspended'才是真卡住，running可能只是慢
长事务拆分时，UPDATE 分批失败的常见原因
不是所有数据都能简单按 TOP N 切——主键不连续、索引缺失、WHERE 条件没走索引，都会让每次扫描都重扫全表，越往后越慢。
实操建议：
- 必须用有界条件分片：比如按
id BETWEEN @start AND @end，而不是TOP 1000+NOT IN (SELECT ...) - 确保分片字段上有索引，且该索引是查询谓词中「最左前缀」可用的（例如 WHERE
created_date >= '2024-01-01'，就要有(created_date, id)覆盖索引） - 每次提交后加
WAITFOR DELAY '00:00:00.1'，避免连续争抢同一页锁（特别是聚集索引尾页）
SET LOCK_TIMEOUT 设太小反而更易失败？
设成 1000（1秒）看似防卡死，但实际会让大量短等待直接抛出 Timeout expired 错误，掩盖真实瓶颈；而设为 0（立即报错）又失去重试机会。
实操建议：
- 线上存储过程里不要全局设
SET LOCK_TIMEOUT，它影响整个批处理，包括日志写入、临时表操作等隐式锁 - 只在明确知道可能被阻塞的 DML 前后加：比如在
UPDATE前用SET LOCK_TIMEOUT 5000，执行完立刻SET LOCK_TIMEOUT -1恢复默认 - 配合应用层重试逻辑：超时后查
sys.dm_tran_locks确认是否真被阻塞，而非死锁，再决定是否重试
拆分逻辑后性能没提升，甚至更慢？
本质是把「单次大锁」换成了「多次小锁 + 更多日志和事务开销」。尤其当每批只改几行，却频繁提交，日志刷盘、锁申请/释放、事务管理成本反超收益。
实操建议：
- 单批行数不是越多越好：SQL Server 单事务建议控制在 5000 行以内，超过容易触发锁升级（
LOCK_ESCALATION = TABLE） - 关闭自动提交，手动控制
BEGIN TRAN/COMMIT，但每批仍需独立事务——不能把 10 批包进一个事务，否则锁持续时间没变 - 检查
tempdb是否成为瓶颈：分批过程若大量用##temp或排序，tempdb文件不足会拖垮整体速度
锁等待超时从来不是孤立问题，它总连着事务边界是否合理、索引是否覆盖、甚至客户端连接池配置。最容易被忽略的，是拆分后没验证锁粒度是否真的变细——用 sys.dm_tran_locks 对比拆分前后 resource_type（KEY vs PAGE vs OBJECT）的变化，比看执行时间更可靠。
