nolock仅适用于select语句，对update、delete、insert等写操作无效；它允许脏读但不改变写操作的排他锁行为，无法解决写-写死锁问题。
NOLOCK 对 UPDATE/DELETE 无效，它只影响 SELECT
NOLOCK（即 READ UNCOMMITTED）只是查询提示，仅改变 SELECT 语句的读取行为：跳过共享锁（S 锁），允许脏读。但它完全不干预写操作——UPDATE、DELETE、INSERT 仍会按隔离级别申请排他锁（X 锁），且锁的申请顺序、持有时间、范围都不受 NOLOCK 影响。
所以当两个存储过程因 UPDATE order_items SET qty = qty - 1 WHERE order_id = @id 相互等待对方持有的 X 锁时，给里面的 SELECT 加 WITH (NOLOCK) 没有任何作用——死锁发生在写锁之间，不是读写之间。
加 NOLOCK 反而可能掩盖真实问题，甚至加剧竞争
在“先查后更”类逻辑中盲目加 NOLOCK，会让多个事务同时读到旧值（比如库存都是 10），然后都执行 UPDATE ... SET qty = 9，造成超卖。这虽不直接导致死锁，但会提升写冲突概率，尤其在高并发下更容易触发 1205 错误。
- 它无法消除写-写冲突，而这类冲突正是死锁主因
- 它绕过锁兼容性检查，让本该被阻塞的读提前完成，可能使事务生命周期拉长，间接延长写锁持有时间
- 若存储过程中有
IF EXISTS(SELECT ... WITH (NOLOCK))+INSERT，可能引发重复插入或丢失更新，后续清理又引入新锁争用
真正该检查的是写操作的锁序与事务边界
死锁日志里如果看到两个 UPDATE 的 waitresource 都指向同一行（如 KEY: 6:72057594044837888 (b5e8a2d7c1f9)），说明问题出在写路径上。此时要盯住：
- 是否所有涉及多表更新的存储过程，都严格按相同顺序访问表（例如总是先
UPDATE orders再UPDATE order_items） - 事务是否包裹了非数据库操作（如 HTTP 调用、文件读写），导致 X 锁持有时间远超预期
- WHERE 条件是否走索引？全表扫描会升级为页锁或表锁，极大增加锁冲突面
- 有没有显式使用
UPDLOCK或HOLDLOCK却没配对ROWLOCK，导致锁粒度意外放大
SNAPSHOT 隔离也救不了写-写死锁，别迷信“读已提交快照”
即使启用了 READ_COMMITTED_SNAPSHOT ON，UPDATE 依然会对目标行加 X 锁；两个事务同时更新同一行，必然一个等另一个释放锁——若此时它们又各自持有了对方需要的另一把锁，1205 照样报。快照隔离只消除了读-写阻塞，不是万能锁调度器。
真正容易被忽略的点是：很多团队开了 READ_COMMITTED_SNAPSHOT 就以为万事大吉，却没改存储过程里的 SET TRANSACTION ISOLATION LEVEL，也没清理掉残留的 WITH (TABLOCK) 或 sp_getapplock，结果锁争用照旧，还多了 tempdb 压力。
