所有Select加 With (NoLock)解决阻塞死锁 在查询语句中使用 NOLOCK 和 READPAST  处理一个数据库死锁的异常时候，其中一个建议就是使用 NOLOCK 或者 READPAST 。有关 NOLOCK 和 READPAST的一些技术知识点：  对于非银行等严格要求事务的行业，搜索记录中出现或者不出现某条记录，都是在可容忍范围内，所以碰到死锁，应该首先考虑，

WITH(NOLOCK) 是一种 SQL Server 中的表提示（table hint），可以用来告诉数据库引擎在查询数据时不要加锁，以避免因为锁等待导致查询性能下降。 当多个事务同时访问同一张表时，数据库引擎会对表进行锁定，以确保事务的隔离性和一致性。这样可以避免在并发访问的情况下发生数据冲突或不一致的情况。但是，在高并发的情况下，加锁可能会导致查询性能下降，因为其他事务需要等待锁的释放才能

最近刚换了工作，数据库也换了，看函数的时候发现里面有nolock这个用法，例如：sleect * from table_name with(nolock) 于是搜索了很多，现在做一个总结 nolock： 其实说白了，就是数据库机制不同导致的， MySQL、Oracle默认情况是不会发生阻塞现象，不会读取脏数据的，也就是说不会出现一行数据不完整的情况 而SqlServer不一样，如果此时有

概念介绍    开发人员喜欢在SQL脚本中使用WITH(NOLOCK), WITH(NOLOCK)其实是表提示（table_hint）中的一种。它等同于 READUNCOMMITTED 。 具体的功能作用如下所示（摘自MSDN）：    1： 指定允许脏读。不发布共享锁来阻止其他事务修改当前事务读取的数据，其他事务设置的排他锁不会阻碍当前事务读取锁定数据。允许脏读可能产生较多的并发操作，但其代价

1：我做了一个实验。 首先创建表，并插入一些数据，sql脚本如下 CREATE TABLE dbo.tb(      c1 int,      c2 char(10),      c3 varchar(10) ); GO DECLARE @id int; SET @id = 0; WHILE @id <5 BEGIN