当测量我的查询性能，我想出了隔离级别之间的依赖和使用时间，这是令人惊讶的对我为什么更好的隔离级是指在SQL Server性能更好
READUNCOMMITTED - 409024
READCOMMITTED - 368021
REPEATABLEREAD - 358019
SERIALIZABLE - 348019
左列表提示，并右列是经过的时间（以微秒为单位）（sys.dm_exec_query_stats.total_elapsed_time）。为什么更好的隔离级别提供更好的性这是一个开发机器，不会发生任何并发。由于减少了锁定开销，我期望READUNCOMMITTED成为禁食。
更新：我做了
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
衡量这一点，并探查证实是有没有缓存命中发生。
首先，您需要在每个隔离级别下重复运行查询，并对结果进行平均，丢弃最大时间的查询。这将消除缓冲区预热影响：您希望所有运行都处于热缓存中，而不是有一个查询预热缓存并相比较而言付出代价。
接下来，您需要确保在实际并发场景下进行测量。如果您将在现实生活中发生更新/插入/删除操作，那么您必须将它们添加到您的测试中，因为它们会在各种隔离级别下极大影响读取。最后你想要得出的结论是'可序列化的读取速度最快，可以在任何地方使用它们'，然后在生产中观察系统融化，因为所有内容都是序列化的。
除此之外，合法更快的唯一隔离级别是脏读，因为它不获取锁。读取已提交的快照（您未测量）也不会获取锁定，但由于行版本控制开销，它确实会影响整体性能。
请在我的问题中找到更新以解决您的回复中的一些要点。 “脏读”你的意思是READUNCOMMITTED，对不对？ – 2010-03-15 22:48:22
1）在冷缓存上运行查询不准确。您的生产查询不会在冷藏缓存上运行，您将优化一个不切实际的方案，并且不会测量查询，您实际上是在测量磁盘读取吞吐量。您还需要在温暖的高速缓存上测量性能，并跟踪两者（冷运行时间，温暖运行时间）。 2）读取未提交脏读。 – 2010-03-15 23:55:51
在一般情况下，对于特定数据只运行一次的大型查询（数百万行）的缓存有多相关？ – 2010-03-16 00:08:50
现在我更好地理解隔离级别，我发现更好的隔离级别可以允许一些智能优化。例如，一旦事务读取一些数据隔离级别可能会规定它应该使用该数据直到最后，而不是尝试从磁盘重新读取它们。
我仍然会有兴趣阅读一些这方面的深入了解。
我当然有这样的习惯，谢谢提醒。 Remus提供了相当宝贵的意见，但我仍希望了解为什么我观察到的现象发生。 – 2010-03-16 10:55:35