我公司聘请来解决死锁问题的 DBA 刚刚告诉我，如果我们将事务级别从 READ UNCOMMITTED 设置为 READ COMMITTED，我们的 OLTP 数据库锁定问题将会得到改善。
这不是100％错误吗？READ COMMITTED 会导致更多的锁，对吗？
更多细节：
我们的数据非常“孤立”且用户特定。99.9999999% 的用户交互都使用您自己的数据，而我们的脏读场景（如果发生）几乎不会影响用户尝试执行的操作。
感谢所有答案，有问题的 dba 最终变得无用，我们通过添加单个索引解决了锁定问题。
我很遗憾我没有指定更新语句而不是常规选择发生的锁定问题。从我的谷歌搜索来看，两种不同的查询类型在处理锁定问题时有不同的解决方案。
这听起来确实有点轻率的决定，但是如果没有您环境的所有细节，就很难说。
您应该建议您的 DBA 考虑使用 SQL Server 的高级隔离功能，即使用行版本控制技术。这被引入到 SQL Server 2005 以专门解决遇到高锁定的 OLTP 数据库的问题。
以下白皮书包含相当复杂的主题，但它是所有优秀 DBA 的必读之物。它包括如何在不同类型的环境（即 OLTP、卸载报告环境等）中使用每个附加隔离级别的示例。
http://msdn.microsoft.com/en-us/library/ms345124.aspx
总而言之，如果没有首先深入了解过度锁定在您的环境中是如何发生的，就修改所有 T-SQL 查询的事务隔离是愚蠢和轻率的。
我希望这会有所帮助，但如果您需要进一步澄清，请告诉我。
干杯!
这不取决于您的问题是什么：例如，如果您的问题是死锁，锁定级别的增加可能不会导致更早获得锁，从而降低致命拥抱的可能性吗？
如果数据是孤立的并且您仍然遇到死锁，那么您可能只需要向导致问题的查询添加行锁提示，以便在行级别而不是页级别（这是默认设置）获取锁。
如果您因为 SELECT 语句而锁定数据，READ UNCOMMITTED 将减少锁定的数量。如果您因为 INSERT、UPDATE 和 DELETE 语句而锁定数据，那么将隔离级别更改为 READ UNCOMMITTED 不会为您做任何事情。READ UNCOMMITTED 与在查询中添加 WITH (NOLOCK) 具有相同的效果。
这听起来很可怕。您真的只想更改这些参数以避免死锁吗？也许需要锁定数据？
也就是说，DBA 可能指的是新的（自 SQL Server 2005 起）READ COMMITTED SNAPSHOT，它使用行版本控制并且可以消除某些类型的死锁。