我们的客户遇到了数据库应用程序的一些阻塞问题。我们要求他们运行阻塞进程报告跟踪，他们给我们的跟踪显示在SELECT和UPDATE操作之间发生阻塞。跟踪文件显示以下内容：
基本上我们不知道为什么SELECT查询的隔离级别不是默认的ReadCommitted IsolationLevel，更令人困惑的是，为什么查询的IsolationLevel会随着时间的推移而改变？只有一个客户看到此行为，因此我们怀疑它可能是数据库配置问题。
有什么想法吗？
提前致谢，
格雷厄姆
答案 0 :(得分：6)
在您的场景中，我建议显式设置隔离级别为快照 - 这将阻止读取通过阻止锁定来阻止写入（插入和更新），但那些读取仍然是“好”读取（即不脏数据 - 它与NOLOCK不同）
通常我发现我的查询存在锁定问题，我手动控制应用的锁定。例如我会用行级锁进行更新以避免页面/表级锁定，并将我的读取设置为readpast（接受我可能会遗漏一些数据，在某些情况下可能没问题） 链路|编辑|删除|标志
编辑 - 将所有评论合并到答案中
作为优化过程的一部分，sql server避免在知道未更改的页面上获取提交读取，并自动回退到较小的锁定策略。在您的情况下，sql server从可序列化读取中删除到可重复读取。
问：感谢有关删除隔离级别的有用信息。你能想到它首先会使用Serializable IsolationLevel的原因，因为我们没有为SELECT使用显式事务 - 我们理解隐式事务会使用ReadCommitted吗？
答：默认情况下，SQL Server将使用Read Commmited，如果这是您的默认隔离级别但是如果您不在查询中另外指定锁定策略，则基本上是对sql server说“做你认为最好的，但我的偏好是Read Commited“。由于SQL Server可以自由选择，因此它可以优化查询。 （sql server中的优化算法非常复杂，我自己并不完全理解它）。未明确在事务中执行不会影响sql server使用的隔离级别。
问：最后一点，SQL Server是否会增加隔离级别（可能是所需的锁数）来优化查询似乎是合理的？我还想知道如果它继承了最后使用的隔离级别，重用池化连接是否会影响它？答：Sql server将作为名为“Lock Escalation”的进程的一部分执行此操作。从http://support.microsoft.com/kb/323630，我引用：“Microsoft SQL Server动态地确定何时执行锁定升级。在做出此决定时，SQL Server会考虑特定扫描中保留的锁定数量，锁定的数量是由整个事务保存，以及整个系统中用于锁定的内存。通常，SQL Server的默认行为导致锁定升级只发生在可以提高性能或必须减少过多系统锁定的那些点上内存到更合理的级别。但是，某些应用程序或查询设计可能会在不需要时触发锁升级，并且升级的表锁可能会阻止其他用户“。
虽然锁升级与更改查询运行的隔离级别不完全相同，但这让我感到惊讶，因为我不希望sql server占用比默认隔离级别允许的锁更多的锁。
答案 1 :(得分：3)
有关SQL为何会通过升级获取更多锁定的更多信息：这是不正确的，升级会减少（不增加）所需的锁定数量。表锁是单个锁，而不是从较低级别执行相同操作所需的所有页锁或行锁。锁定升级总是出于一个原因：采用更高级别的锁定比锁定所有更低级别的对象更有效
例如，可能没有可用于有效锁定的索引。即如果你在一个字段中对2010年的所有记录进行UPDLOCK计数，并且该日期字段上没有索引，这将需要在2010年对每条记录进行行锁定，如果有很多记录被击中则效率不高并且页面锁定也无济于事，因为它们可能是跨页面随机分布的，因此SQL会占用表锁定。此外，SQL还必须锁定其他记录，而不是在UPDLOCK保持时在2010年进行更改，并且在此字段上没有索引来执行范围锁定，SQL没有选择但是采取表锁定以防止这种情况发生。后一点是优化新手经常忽略的一点：认识到SQL还必须“保护”已在事务中执行的查询的完整性。